Web-to-Host Connectivity

BEST PRACTICES SERIES Web-to-Host Connectivity THE AUERBACH BEST PRACTICES SERIES Broadband Networking, James Trulov...

Author: Anura Guruge

145 downloads 3693 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

BEST PRACTICES SERIES

Web-to-Host Connectivity

THE AUERBACH BEST PRACTICES SERIES Broadband Networking, James Trulove, Editor, ISBN: 0-8493-9821-5 Electronic Messaging, Nancy Cox, Editor, ISBN: 0-8493-9825-8 Financial Services Information Systems, Jessica Keyes, Editor, ISBN: 0-8493-9834-7 Healthcare Information Systems, Phillip L. Davidson, Editor, ISBN: 0-8493-9963-7 Internet Management, Jessica Keyes, Editor, ISBN: 0-8493-9987-4 Multi-Operating System Networking: Living with UNIX, NetWare, and NT, Raj Rajagopal, Editor, ISBN: 0-8493-9831-2 Network Manager’s Handbook, John Lusa, Editor, ISBN: 0-8493-9841-X Project Management, Paul C. Tinnirello, Editor, ISBN: 0-8493-9998-X Server Management, Gilbert Held, Editor, ISBN: 0-8493-9823-1 Enterprise Systems Integration, John Wyzalek, Editor, ISBN: 0-8493-9837-1 Web-to-Host Connectivity, Lisa Lindgren and Anura Guruge, Editors ISBN: 0-8493-0835-6 Network Design, Gilbert Held, Editor, ISBN: 0-8493-0859-3

AUERBACH PUBLICATIONS www.auerbach-publications.com TO ORDER: Call: 1-800-272-7737 • Fax: 1-800-374-3401 E-mail: [email protected]

BEST PRACTICES SERIES

Web-to-Host Connectivity Editors

ANURA GURUGÉ LISA LINDGREN

Boca Raton London New York Washington, D.C.

Library of Congress Cataloging-in-Publication Data Web-to-host connectivity / Anura Gurugé and Lisa M. Lindgren, editors. p. cm. Includes index. ISBN 0-8493-0835-6 (alk. paper) 1. Web servers. 2. Intranets (Computer networks) 3. Extranets (Computer networks) 4. Browsers (Computer programs) I. Gurugé, Anura. II. Lindgren, Lisa. TK5105.888.W3738 2000 004.6—dc21 00-026822 CIP This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microfilming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. All rights reserved. Authorization to photocopy items for internal or personal use, or the personal or internal use of specific clients, may be granted by CRC Press LLC, provided that $.50 per page photocopied is paid directly to Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923 USA.The fee code for users of the Transactional Reporting Service is ISBN 0-8493-0835-6/00/$0.00+$.50. The fee is subject to change without notice. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. The consent of CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. Specific permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation, without intent to infringe.

© 2000 by CRC Press LLC Auerbach is an imprint of CRC Press LLC No claim to original U.S. Government works International Standard Book Number 0-8493-0835-6 Library of Congress Card Number 00-026822 Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 Printed on acid-free paper

iv

Contributors MARY AYALA-BUSH, Principal, Computer Sciences Corporation, Waltham, Massachusetts ED BAILEY, Senior Engineer, IBM, Research Triangle Park, North Carolina NIJAZ BAJGORIC, Faculty, Bogazici University, Istanbul, Turkey MICHAEL BLANK, Senior Engineer, WebMethods, Inc., Fairfax, Virginia MARION CERUTI, Scientist, Advanced C41 Systems, Engineering and Integration Group, Command and Intelligence Systems Division, Naval Command, Control, and Ocean Surveillance Center, RDT&E Division, San Diego, California CARLSON COLOMB, Director, Aviva Marketing, Eicon Technologies, Montreal, Quebec, Canada CHRIS FORSYTHE, Senior Member, Technical Staff, Statistics and Human Factors Department, Sandia National Laboratories, Albuquerque, New Mexico JIM FOXWORTHY, Director, Product Marketing, VM Software Division, Sterling Software, Reston, Virginia MONICA J. GARFIELD, Doctoral Student, MIS, University of Georgia, Athens, Georgia IDO GILEADI, Manager, Deloitte & Touche Consulting Group, Toronto, Ontario, Canada ANURA GURUGÉ, Independent Technical Consultant, Meredith, New Hampshire GILBERT HELD, Director, 4-Degree Consulting, Macon, Georgia JOHN JORDAN, Principal, Consulting & Systems Integration, Computer Sciences Corporation, Waltham, Massachusetts DONNA KIDDER, Product Line Manager, InterWorks Business Unit, Cisco Systems, Inc., Research Triangle Park, North Carolina DAVE KING, Director of Research and Innovation, Comshare, Inc. RALPH L. KLIEM, President, Practical Creative Solutions, Inc., Redmond, Washington PAUL KORZENIOWSKI, Freelance Writer, Sudbury, Massachusetts WALTER KUKETZ, Consulting and Systems Integration, Computer Sciences Corporation, Waltham, Massachusetts CAROL L. LARSON, Freelance Desktop Publisher, Hillsboro, Oregon JAMES A. LARSON, Senior Software Engineer, Intel Architecture Lab, Hillsboro, Oregon v

RICHARD J. LEWIS, eCom Connections, Cincinnati, Ohio LISA M. LINDGREN, Independent Consultant, Meredith, New Hampshire DAVID LITWACK, President, dml Associates, Fairfax, Virginia JEFFREY J. LOWDER, Network Security Element Chief, United States Air Force Academy, Colorado Springs, Colorado HOWARD MARKS, Chief Scientist, Networks Are Our Lives, Inc., Sherman, Connecticut PATRICK G. MCKEOWN, Professor of Management, Terry College of Business, University of Georgia, Athens, Georgia J.P. MORGENTHAL, Java Computing Analyst, nc.focus, New York, New York NATHAN J. MULLER, Consultant, The Oxford Group, Huntsville, Alabama JAN MURPHY, Technical Communications Manager, Persoft Inc., Madison, Wisconsin WILLIAM H. MURRAY, Executive Consultant, Deloitte & Touche LLP, New Canaan, Connecticut DOUG NICKERSON, Software Engineer, Cape Cod, Massachusetts SRINIVAS PADMANABHARAO, Consultant, Deloitte Consulting, Toronto, Ontario, Canada GALE PERSIL, Product Manager, Network Management, Sterling Software, Reston, Virginia T.M. RAJKUMAR, Associate Professor, Department of Decision Sciences and MIS, Miami University, Oxford, Ohio JAMES A. SENN, Director, Information Technology Management Group, College of Business Administration, Georgia State University, Atlanta, Georgia DUANE E. SHARP, President, SharpTech Associates, Mississauga, Ontario, Canada BILL STACKPOLE, Olympic Resource Management, Poulsbo, Washington BHAVANI THURAISINGHAM, Lead Engineer, Center for Integrated Intelligence Systems, The MITRE Corporation, Bedford, Massachusetts RICHARD TOBACCO, Brand Manager, Network Computing Software Division, IBM GARY TYREMAN, Senior Director of Product Marketing, Network Connectivity, Hummingbird Communications, Toronto, Ontario, Canada JASON WEIR, Technical Writer, DataMirror Corporation, Markham, Ontario, Canada TODRES YAMPEL, President and Chief Operating Officer, ResQNet.com, Inc., New York, New York

vi

Table of Contents INTRODUCTION ........................................................................................................... xi SECTION I 1

2

3

4 5 6 7 8

APPLICATIONS FOR WEB-TO-HOST INTEGRATION ....... 1 Web-to-Host Integration: An Overwhelming Vote of Confidence....................................................................................... 3 Carlson Colomb and Anura Gurugé Knowledge Management on the Internet: The Web/Business Intelligence Solution..................................................................... 17 Jason Weir Expanding the Reach of Electronic Commerce: The Internet EDI Alternative ....................................................... 27 James A. Senn Business-to-Business Integration Using E-commerce .............. 41 Ido Gileadi Web-to-Information-Base Access Solutions ............................... 49 Marion Ceruti Enabling Consumer Access to Business Databases ................. 63 James A. Larson and Carol L. Larson Web-Enabled Data Warehouses................................................... 79 Mary Ayala-Bush, John Jordan, and Walter Kuketz Real-Life Case Studies of Web-to-Host Integration ................... 89 Anura Gurugé

SECTION II 9 10 11

12 13

WEB-TO-HOST ACCESS TECHNOLOGIES ...................... 107

The Enterprise Intranet Series: Web-to-Host Technology ..... 109 Gary Tyreman Web-to-Host Connectivity Tools in Information Systems ...... 119 Nijaz Bajgoric Survival of the Fittest: The Evolution to Thin-Client Intranets....................................................................................... 139 Jan Murphy tn3270 and tn5250 Internet Standards ..................................... 149 Ed Bailey Publishing Host Data Using 3270-to-HTML Conversion......... 161 Carlson Colomb vii

14

XML-Based Business-to-Business E-commerce ....................... 171 Michael Blank

SECTION III 15 16 17

Web-Based Technologies for User Interface Rejuvenation.......185 Todres Yampel Usability Design for Web-Based Applications ......................... 197 Chris Forsythe User Interface Rejuvenation Methodologies Available with Web-to-Host Integration Solutions ............................................ 207 Carlson Colomb and Anura Gurugé

SECTION IV 18

19 20

22 23

25

26 27

viii

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES ................................................................. 251

Java's Role in Distributed Computing ...................................... 253 J.P. Morgenthal Component Architectures with JavaBeans.............................. 261 Doug Nickerson Evaluating Object Middleware: DCOM and CORBA................ 269 T.M. Rajkumar and Richard J. Lewis

SECTION VI 24

HOST INTEGRATION AND APPLICATION SERVERS .............................................................................. 219

Application Servers: The Next Wave in Corporate Intranets and Internet Access .................................................................... 221 Lisa M. Lindgren Host Integration Servers ............................................................ 231 Lisa M. Lindgren Microsoft’s “Babylon” — Windows 2000's Interoperability for the Enterprise........................................................................ 239 Anura Gurugé

SECTION V 21

HOST APPLICATION USER INTERFACE REJUVENATION ................................................................. 183

SECURITY ............................................................................ 287

Framework for Internet Security Planning............................... 289 Monica J. Garfield and Patrick G. McKeown Developing a Trusted Infrastructure for Electronic Commerce Services .................................................................... 299 David Litwack Application-Layer Security Protocols for Networks............... 313 Bill Stackpole Security of Communication Protocols and Services .............. 331 William H. Murray

28 29 30

Firewall Management and Internet Attacks............................. 345 Jeffery J. Lowder Internet-Based Virtual Private Networks ................................. 361 Nathan Muller The Evolving World of Network Directory Service ................ 373 Gilbert Held

SECTION VII 31 32

33 34

Integrating Data Centers with Intranets .................................. 385 Anura Gurugé Gracefully Transitioning from SNA to IP: Why, How, and When?........................................................................................... 397 Anura Gurugé One Corporate Network — Dream or Nightmare?.................. 409 Donna Kidder Enterprise Extender: A Better Way to Use IP Networks......... 419 Richard J. Tobacco

SECTION VIII 35

36 37 38 39

40

42 43

44

SERVER INFRASTRUCTURE............................................. 427

Selecting Hardware and Operating System Software for E-commerce ................................................................................. 429 Duane E. Sharp Server Issues and Trends, 2000 ................................................ 437 Howard Marks Web Site Design and Performance for Intranets ..................... 449 Ralph L. Kliem Linux and the Web ...................................................................... 457 Srinivas Padmanabharao Web-to-Host with VM/ESA: A Viable Platform for the Internet......................................................................................... 465 Jim Foxworthy Why Parallel Sysplex is a Must for Today's IBM Data Centers ......................................................................................... 475 Anura Gurugé

SECTION IX 41

INTEGRATING LEGACY TRAFFIC................................... 383

SYSTEM AND NETWORK MANAGEMENT ..................... 487

Principles and Applications of Key Management................... 489 William H. Murray Web Server Monitoring .............................................................. 503 WRQ, Inc. Database Management and the Internet: Development and Challenges.................................................................................... 511 Bhavani Thuraisingham OLAP Agents: Monitoring the Data Warehouse ...................... 519 Dave King ix

45 46

Enterprise Data Management with CIM and XML ................... 527 Paul Korzeniowski Maximizing Mainframe-Based WAN Resources ....................... 535 Gale Persil

Final Word................................................................................................ 547 About the Editors.................................................................................... 549 Index ......................................................................................................... 551

x

Introduction Nobody can dispute the incredible impact that the Web continues to have on the way in which people work, shop, research, play, and communicate. In the span of just a few short years, enterprises in nearly every industry and market have had to reevaluate the way in which they do business with their business partners and end customers. Having a presence on the Web has become an absolute necessity for large and small enterprises alike. But a mere Web presence in the form of online “brochure-ware” is not enough. Enterprises must provide their business partners and end customers with advanced services through their Web sites. Examples abound and include home banking, package tracking, order entry, order status inquiry, and other customer services. It is quickly becoming an accepted notion that businesses without a Web strategy will cease to exist within a few short years. The incredible challenge facing IT management is how to provide these advanced services in the face of flat budgets, scarce labor, and Y2K upgrades. Because the advanced Web-based services tap into the operational heart of the enterprise, it is imperative that IT management leverages the existing, mission-critical applications and data. There is neither the time nor the budget to rewrite and port everything to Web servers. IT staff must integrate the existing systems with new, burgeoning corporate intranets being developed. Web-to-host integration is the most pressing, but equally the most rewarding, challenge facing IT professionals around the world. Web-to-host integration permits the proven, mission-critical data center systems and applications to be seamlessly and synergistically assimilated with Internet technology-based networks and Web server-based information infrastructures. Web-to-host integration permits PC, Apple Mac, and workstation users to effortlessly access data center applications and databases via a standard Web browser such as Netscape Navigator or Microsoft Internet Explorer — across the global Internet, a corporate-specific intranet, or a business-to-business extranet. Web-to-host integration also permits data resident on legacy systems to be easily incorporated into highly visual, multimedia Web pages that also happen to include data from other sources — including Web servers. xi

This book is the first of its kind, offering the reader a comprehensive overview of the possibilities of Web-to-host integration in addition to the relevant technologies and issues. It covers a broad range of topics relevant to the subject, and provides compelling and useful information for a wide variety of audiences — from the business manager who needs to justify a Web-to-host integration project to the network engineer who will need to design, install, or manage such an effort. The book contains 46 chapters organized in nine sections. Each section contains a logical grouping of related chapters. The book may, of course, be read serially from one chapter to the next. However, the reader may instead choose to skip around, reading only those chapters that pertain to a current task or goal. The first section introduces the subject matter and provides specific examples of how Web-to-host integration can be used in real-world applications. The second section details the technologies utilized to provide Webto-host access. Because many legacy systems utilize dated character-based interfaces, it is often important for organizations to update or “rejuvenate” these applications with a more modern, Web-style GUI front end. The third section discusses technologies and guidelines for providing this Web-style interface. Achieving Web-to-host integration, in some cases, involve more than a simple on-the-fly conversion gateway. Enterprises may need to begin to develop new applications that tap legacy applications and data in addition to performing new functions. The fourth section provides details on server-based application servers and host integration services to aid in this step. The fifth section discusses some of the relevant object-oriented architectures and programming technologies. Although Web-to-host integration projects differ in many ways from other Web server projects, there are some common issues and concerns that must be addressed. Sections VI through IX offer information on some of these issues and concerns. Section VI discusses security technologies that allow safe and secure access to legacy systems and applications. Section VII provides information on how enterprises can integrate their legacy traffic into the new infrastructure that is based on TCP/IP and Internet technologies. Section VIII discusses server infrastructure issues, some of which are unique to Web-to-host integration and some of which apply to any Web project. Finally, Section IX concludes the handbook with a survey of issues related to system and network management. The editors certainly hope that the reader will enjoy this first-of-its-kind book and welcome any comments. Please send comments to the editors via e-mail to [email protected] or addressed to the editors through the publisher by mail at: xii

Auerbach Publications 535 Fifth Ave., Suite 806 New York, NY 10017

Best regards and cheers, Anura Gurugé Lisa M. Lindgren

xiii

Acknowledgments The editors wish to thank all of the authors who contributed to this book. We are lucky to have access to such a talented group of individuals, each of whom brings a unique background and perspective to the subject area. We would especially like to thank Todres Yampel of ResQNet.com and Carlson Colomb of Eicon Technology for their dedicated and responsive effort, providing some very useful and insightful articles on very short notice. Theron Shreve and Claire Miller, both of Auerbach Publications, deserve our heartfelt gratitude for coordinating this project and making it happen.

xv

Section I

Applications for Web-to-Host Integration THE POSSIBLE APPLICATIONS FOR WEB-TO-HOST INTEGRATION ARE ABOUT as numerous and varied as there are legacy applications. Early implementers of Web-to-host integration projects, however, have shown that there are some common types of projects that have big payoffs, including remote access, business-to-business E-commerce, and consumer E-commerce. This section introduces the possible types of applications that enterprises are making accessible via the Web. Chapter 1 introduces Web-to-host integration, providing a definition of Web-to-host integration, a list of the major techniques for Web-to-host integration, and a list of the immediate uses for and benefits of Web-to-host integration. Chapters 2 through 7 provide examples of the types of legacy systems that are being made accessible from the Web. Chapter 8 concludes the section by presenting six varied, real-life case studies of enterprises that have implemented Web-to-host technologies.

1

Chapter 1

Web-to-Host Integration: An Overwhelming Vote of Confidence Carlson Colomb and Anura Gurugé

WEB-TO-HOST INTEGRATION, NOW THAT Y2K IS HISTORY, IS THE MOST pressing, but equally the most rewarding, challenge facing MIS professionals around the world. Web-to-host integration permits the proven, missioncritical data center systems and applications to be seamlessly and synergistically assimilated with Internet technology-based networks and Web server-based information infrastructures. Web-to-host integration permits PC, Apple Mac, and workstation users (e.g., UNIX) to effortlessly access data center applications and databases via a standard Web browser such as Netscape Navigator or Microsoft Internet Explorer — across the global Internet, a corporate-specific intranet, or a business-to-business extranet. Web-to-host integration also permits data resident on IBM (or compatible) mainframes or AS/400 minicomputers to be easily incorporated into highly visual, multimedia Web pages that also happen to include data from other sources — including Web servers. Web-to-host integration ensures that existing data centers with their traditional systems can be an integral and invaluable component in twentyfirst century, Web-based information systems. Furthermore, with Web-tohost integration, corporations can easily leverage their highly proven and ultra-reliable data center applications that successfully sustain their current day-to-day operation to also work, very effectively, in new Web-centric E-commerce applications — where E-commerce, which will account for over one trillion dollars a year by 2002, is the exciting new trading frontier of twenty-first century commerce. Web-to-host integration is already being very successfully used for online investing (e.g., Charles Schwab), homebased travel reservations (e.g., Sabre), home banking (e.g., Bank of Boston), and Web-based package tracking (e.g., FedEx). These application scenarios demonstrate one of the most alluring strengths of Web-to-host technology — that of permitting the general public with ready and transparent access, over the Internet, to mainframe-resident “legacy” applications. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

3

APPLICATIONS FOR WEB-TO-HOST INTEGRATION In addition to facilitating E-commerce and public-to-host access, Web-tohost integration technology can be gainfully employed by corporations to significantly reduce remote access costs, emulation software costs, and client system maintenance costs. Consequently, Web-to-host technology is definitely a win–win proposition, whichever way one looks at it — with no discernable downside now that this technology is imbued with extensive and watertight security features. Given its overall potential and promise, Web-to-host integration is the most important technological innovation, vis-à-vis the data center, since the advent of the PC in 1981. Over the next decade, Web-to-host integration will even surpass the impact that PCs have made on corporate computing to date by totally redefining and extending the scope, reach, and depth of data center-related applications and operations. ALL HOSTS ARE NOT THE SAME WHEN IT COMES TO WEB-TO-HOST INTEGRATION Web-to-host integration, in theory, applies to all initiatives and methodologies that enable data and applications from existing computer systems, irrespective of their type, to be accessible to Web-based information systems. In practice, the overriding significance and applicability of Web-tohost integration invariably relates to the efforts required to combine traditional IBM-oriented data centers having mainframes or AS/400s with Internet technology-based networks and systems. The reason for this is that one cannot, in many cases, directly tap into mainframe or AS/400 data or applications from a Web browser, across the Internet or an intranet, without some explicit — and often stand-alone — gateway technology to perform the necessary protocol and data conversions to bridge the decadesold IBM data center methodologies with the new conventions of the Internet. For example, IBM data center systems favor SNA for their end-to-end communications and present data using the terminal-oriented 3270 and 5250 data streams. In marked contrast, Internet-based networks and systems rely exclusively on TCP/IP as their networking protocol and prefer to present information using HTML (and XML in the future). An equivalent technological mismatch does not occur with other possible host systems — in particular UNIX- and NT-based servers. UNIX and NT servers make up much of today’s Web-based information environments, including the Internet per se. Consequently, easily integrating data and applications residing on UNIX or NT servers into a Web infrastructure is invariably very straightforward with most Web tools, including Web servers, containing standard features for accessing data on NT and UNIX servers. Thus, Web-to-host integration, when it involves just NT or UNIX servers, typically happens as an unremarkable and undistinguished step in the overall Web-enablement initiative. 4

Web-to-Host Integration: An Overwhelming Vote of Confidence The good news is that the technology to facilitate Web-to-host integration that involves mainframes and AS/400s is now highly proven, readily available, extremely reliable — and moreover, offers extensive security measures such as end-to-end Secure Sockets Layer (SSL)-based authentication and encryption to guarantee the safe and uncompromised passage of data across the Internet, an intranet, or an extranet. In addition to sound security measures, easily realizable and dramatic user interface rejuvenation is another value-added feature of most leading IBM-oriented Web-to-host solutions. In some instances, the harsh and dated “green-onblack” screen interface of mainframe and AS/400 applications can be automatically rejuvenated to create an aesthetically pleasing and highly contemporary look-and-feel without any manual customization or programming through what is referred to as “AutoGUI” capabilities. This user interface rejuvenation, whether through an AutoGUI or a scheme that requires some level of customization, ensures that mainframe or AS/400 applications and data can be readily presented within standard Web pages without the host data appearing to be out of place and anachronistic. Exhibit 1-1 shows some examples of mainframe- and AS/400-based 3270/5250 screens that have been rejuvenated using some of the marketleading Web-to-host solutions. MAJOR TECHNIQUES FOR WEB-TO-HOST INTEGRATION Compelling IBM data center-oriented Web-to-host integration solutions are now available from over 50 companies around the world. Some of the key players include companies such as IBM, Eicon Technology, Attachmate, Novell, NetManage, Jacada (formerly Client/Server Technology), ResQNet, Hummingbird, and many others. Despite the multitude of vendors in this arena, the entire universe of the IBM-oriented Web-to-host solutions can be divided into five broad and distinct categories. These are: 1. Traditional full-function 3270/5250 emulators. These veteran emulators (e.g., IBM’s PComm, Eicon’s Aviva for Desktops, and Attachmate’s EXTRA! Personal Client) can provide unrestricted access to SNA applications running on mainframes or AS/400s, across i•nets,1 using either tn3270(E)/tn5250 mode operation or SNA-LAN gatewayspecific “split-stack” mode using TCP/IP between the desktop client and the gateway. tn3270(E) and tn5250 are well-established (i.e., 1985) and widely used client/server industry standards for SNA access over TCP/IP — where a ‘tn’ server performs the TCP/IP-toSNA/APPN protocol conversion as well as encapsulating/deencapsulating the terminal 3270/5250 data stream to/from clients into and out of TCP/IP packets. The most widely used ‘tn’ servers include IBM’s Comms. Server family (e.g., CS/NT and Comms. Server for OS/390); Novell’s NetWare for SAA; Microsoft’s SNA server, and Cisco’s tn3270(E) Server on Cisco 7200/7500 bridge/routers. When 5

Exhibit 1-1.

Examples of 3270/5250 screens from mainframe and AS/400 applications that have been rejuvenated using Web-to-host integration technology.

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

6

Web-to-Host Integration: An Overwhelming Vote of Confidence operating in ‘tn’ mode, the traditional emulators function as tn3270/tn5250 clients. The gateway-specific, TCP/IP-based “splitstack” operation (now referred to as ip3270/ip5250) is very similar to ‘tn’ mode operation — with the key difference being that ‘tn’ is based on an industry standard whereas split-stack mode operation relies on gateway-specific protocols between the desktop client and the gateway. Novell’s NetWare for SAA and Microsoft’s SNA Server are popular examples of SNA-LAN gateways that suppor t ip3270/ip5250 mode of operation. One major advantage that ip3270/ip5250 has over ‘tn’ is that it can support SNA’s LU 6.2 program-to-program protocol between the desktop client and the host application, while ‘tn,’ as yet, is unable to accommodate LU 6.2. 2. Java- or ActiveX-based thin-client 3270/5250 (and Virtual Terminal [VT]) emulators. These are, in effect, Web technology-based, twenty-first century equivalents of the traditional full-function emulators discussed above. Examples of these thin-client emulators include IBM’s Host On-Demand, Eicon’s Aviva for Java, and Hummingbird’s HostExplorer Web, which are all Java based, and ICOM Informatics’ Winsurf Mainframe Access (WMA) and Zephyr’s Passport eClient, which are ActiveX clients. What differentiates these thin-client emulators from traditional fat-client emulators is that thin-clients do not have to be individually and laboriously installed and maintained on every single PC and workstation that requires SNA-based host access. Instead, these thin-client emulators, which are typically 350 Kbytes to 750 Kbytes in size, can be dynamically downloaded from a Web server — with the download being invoked from a standard Web browser. Once downloaded, the emulator will automatically install itself on the client machine and open up a terminal emulation window — either in standard “green-on-black” format if no rejuvenation is being used, or in a contemporary GUI format if some form of user interface rejuvenation has been activated. Java-based emulators will typically execute on the Java Virtual Machine (JVM) now available as a standard feature of Netscape Navigator and Internet Explorer. This makes Java-based terminal emulators platform independent in that their only prerequisite is a standard Web browser. ActiveX emulators, on the other hand, require a Microsoft Windows environment and as such are restricted to PCs running Windows 95/98 or Windows NT. Both Java and ActiveX emulators can be cached on a client machine’s hard drive to preclude the need for repeated downloads each time the user wants to access a host application. Cached emulators are also invoked from a browser, with no difference in appearance or in the procedure used whether the client is downloaded from a Web server or activated from the hard disk. Obviously, however, there is no download time when a cached client is activated. 7

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Before a cached emulator is activated, the browser will send a quick query to the Web server to determine if the server has a newer version of this thin client. If the cached version is the same as that on the server, the browser will immediately activate the cached client. If a newer version of the client is available at the server, the browser will display a message asking the user whether the newer version should be downloaded and then cached for future use or if the older cached version should be activated for this invocation. This automatic and dynamic downloading, caching, and version-checking of Java and ActiveX thin-client emulators totally obviate the significant cost associated with installing, updating, and maintaining traditional fat clients. Functionally, today’s thin-client emulators offer all of the commonly used emulation features, with some even offering high-end, esoteric functions such as all-points-addressable vector graphics. Most thin-client emulators work in tn3270(E)/tn5250 mode, replete with support for SSL-based encryption, print-spooling, and cut-and-paste between windows, whereas a few — most notably ICOM’s WMA — will also work in ip3270/ip5250 mode. There are also some application-specific thin-client emulation solutions, such as IBM’s CICS Gateway for Java. Exhibit 1-2 shows the architecture of a typical Java-based tn3270(E) thin-client emulator, using Eicon’s Aviva for Java as a highly representative example. 3. 3270/5250-to-HTML conversion. This is the thinnest of host access thin-client solutions with a standard browser being the only software required for the client in order to freely access mainframe or AS/400 resident SNA applications. Eicon’s Aviva Web-to-Host Server, Novell’s HostPublisher, Attachmate’s Host Publishing System, and Intelligent Environments’ ScreenSurfer are leading examples of this very alluring Web-to-host technology. 3270/5250-to-HTML conversion is an entirely server-based solution. With 3270-to-HTML conversion, a server-resident data stream conversion module converts 3270 or 5250 data stream from the host, on the fly, to HTML-based Web pages, or vice versa in the case of data being sent to the host by a browser user. Host data converted to HTML-based Web page format is passed to a standard Web server, which then ensures that the Web page is downloaded to the appropriate browser user across an i•net. Thus with this approach, all interactions with mainframe and AS/400 applications are achieved using Web pages. 3270-to-HTML conversion solutions are available on NT, Novell NetWare, IBM OS/390, and IBM VM/ESA systems while on-the-fly 5250-to-HTML solutions are typically restricted to NT platforms. Some applicationspecific HTML conversion solutions are also available, such as IBM’s CICS Internet Gateway and Sterling Software’s VM:Webgateway OfficeVision Interface. The conversion module converses with the host application via a tn3270(E)/tn5250 Server or a SNA-LAN Gateway 8

Web-to-Host Integration: An Overwhelming Vote of Confidence

Exhibit 1-2.

The standard architecture of a Java applet-based thin-client tn3270(E) client using Eicon’s Aviva for Java as a representative example.

(with the Eicon Aviva Web-to-Host Server being one of the few to have a built-in SNA-gateway to allow it to talk directly to the host without the need for an intermediary gateway). Exhibit 1-3 shows the architecture of a quintessential, full-featured 3270-to-HTML conversion solution using Eicon’s Aviva Web-to-Host Server as a good example of this genre. 3270/5250-to-HTML conversion is invariably the best solution for providing the general public with ready access to host applications over the Internet since the only software required at the client end is a standard Web browser. Typically, this approach also tends to work with most browsers, including older versions of Netscape Navigator 9

Exhibit 1-3.

Typical architecture of a feature-rich, top-end 3270-to-HTML conversion solution (with optional value-added features) using Eicon’s Aviva Web-to-Host Server as a representative example.

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

10

Web-to-Host Integration: An Overwhelming Vote of Confidence and Internet Explorer, since there is no dependency on Java support within the browser — unlike the case with Java-based thin-client emulators. On-the-fly 3270/5250-to-HTML conversion also has the advantage over most thin-client emulators in that some level of default user interface rejuvenation is always performed, thus ensuring that users are never confronted with harsh, “green-on-black” 3270/5250 screens. Initial implementations of 3270/5250-to-HTML technology, ca. 1996, were rather utilitarian and austere and lacked support for function keys, light pens, unsolicited host output, as well as the persistent end-to-end connections that enhance overall security. Today, products like Eicon’s Aviva Web-to-Host Server, Novell’s HostPublisher, and Intelligent Environments’ ScreenSurfer offer complete and incisive HTML publishing solutions replete with all of the necessary security and emulation features. 4. Programmatic approaches, including Host Integration Servers and Java Application Servers. In marked contrast to on-the-fly 3270/5250-to-HTML conversion products or even the thin-client emulators, these programmatic schemes are not straight-out-of-thebox solutions. Instead, these solutions require some amount of programming or customization effort before host data or applications can be accessible through a Web browser, across an i•net. The need for programming or customization is typically not a detriment in the case of these solutions. These programmatic solutions, which typically contain extensive object-oriented technology to expedite and simplify software development, are the most powerful, flexible, and far-reaching means of realizing twenty-first century Web-to-host integration. With these programmatic solutions, it is possible to combine, manipulate, reconstitute, and even embellish data from multiple disparate sources — including multiple different host systems. The solutions also offer multiple ways through which data can be presented to end users across an i•net. Some of the possible data presentation options include HTML-based Web pages, HTML Web pages augmented with Java or ActiveX applets, applet-based clients, and object-oriented clients made up of software components from various sources. These programmatic approaches, which include IBM’s Host Publisher V.2, IBM’s MQSeries, Inprise’s Application Server, and BEA WebLogic, are ideally suited for developing new Web-centric applications that require background access to data center resident applications and databases. 5. End-to-end SNA transport mechanisms such as Data Link Switching (DLSw) and HPR-over-IP. Whereas the four techniques discussed above enable non-SNA clients (e.g., Web browsers or thinclient tn3270(E) emulators) to gain access to SNA host applications, this SNA transport category of solutions focuses on enabling SNA traffic to be conveyed end-to-end across TCP/IP-centric 11

APPLICATIONS FOR WEB-TO-HOST INTEGRATION i•nets. These solutions permit legacy SNA devices (e.g., 3x74 [or compatible] control units, IBM 4700 financial systems, automated teller machines [ATMs], and PCs/workstations containing a “fullstack” implementation of SNA) to be gainfully and nondisruptively accommodated within the context of twenty-first century i•nets. DLSw and HPR-over-IP (referred to as Enterprise Extender by IBM and SNA Switching Services by Cisco) are the two leading approaches for end-to-end SNA transport across i•nets. DLSw, which was introduced by IBM in 1992, is now a widely accepted industry standard and readily available on most bridge/routers from the likes of Cisco, IBM, Nortel, and 3Com. HPR-over-IP, a relatively new industry standard compared to DLSw, is now available on Cisco and IBM bridge/routers. Typically, a corporation would use two or more of these Web-to-host integration techniques in parallel to address its entire set of requirements in terms of users, applications and legacy devices. For example, a corporation might use a Java-based thin-client 3270 emulator for its in-house data entry clerks, on-the-fly 3270-to-HTML conversion to provide field representatives with online access over the Internet to an order processing application, and DLSw to take care of its remote offices where there are actually 3270 terminals connected to 3174 control units. Another corporation might elect to use fat clients in tn3270(E) mode for all of the access needs of its employees and 3270-to-HTML conversion to provide the general public with access to an online investing application over the Internet. SECURITY CONCERNS CAN NO LONGER BE USED AS AN EXCUSE Security, in terms of unauthorized interception of data and access to applications, understandably, used to be the overriding concern when it came to Web enabling a data center. The good news is that security is no longer a justifiable stumbling block when it comes to Web-to-host integration. Today’s thin-client emulators, 3270/5250-to-HTML conversion, and programmatic host integration server solutions provide unprecedented, watertight end-to-end security through a combination of user authentication, data encryption, and firewall-based access control. Up to six levels of security can be implemented with most Web-to-host integration solutions. These six levels of security provide watertight safeguards at the session, transport, server, firewall, host, and application levels. Session-level security is provided with the “impenetrable” end-to-end persistent connections employed by tn3270(E)/tn5250 and ip3270/ip5250 sessions. Some of the leading 3270-to-HTML conversion products, such as Eicon’s Aviva Web-to-Host Server, Novell’s HostPublisher and iE’s ScreenSurfer, also provide session persistence between browser users and a Web server using a variety of innovative, product-specific techniques. Trans12

Web-to-Host Integration: An Overwhelming Vote of Confidence port-layer security, whether it be for ‘tn’ sessions or 3270/5250-to-HTML conversion, is ensured by using SSL-based end-to-end encryption. Moreover, some gateways, such as Novell’s NetWare for SAA 4, ensure that the data can be securely encrypted all the way up to the host application by supporting SNA’s Data Encryption Standard (DES) technology-based LU-LU encryption between the gateway and the host. Server-level security is usually realized using SSL or a product-specific scheme to perform user authentication. Some solutions already include support for the strategic Lightweight Directory Access Protocol (LDAP) to facilitate user authentication using standard directory services such as the increasingly popular Novell Directory Services (NDS). Firewall-level security will be enforced by a proven firewall product such as Checkpoint’s FireWall-1 and Cisco’s PIX. Host-level security will typically be arbitrated by a host access control package such as RACF or ACF2, while IBM’s insistence that each application performs its own user ID/password user validation serves as the final level of security. THE KEY ADVANTAGES OFFERED BY WEB-TO-HOST INTEGRATION TECHNOLOGY Now that the options for Web-to-host integration have been described and the issues related to security concerns have been addressed, the primary redeeming characteristics of Web-to-host integration technology can be summarized as follows: • Thin-client methodology dramatically reduces, if not totally eliminates, the cost of installing, upgrading, and maintaining host access software on the PC/workstation of every user that requires access to host applications. • 3270/5250-to-HTML, which is in effect a zero-client solution in that all it requires at the client machine is a standard Web browser, is an optimum, near-zero-cost mechanism to enable the general public to gain access to certain data center applications or to accommodate users who only require occasional casual access to host applications. • The thin-client, 3270/5250-to-HTML conversion and many of the programmatic solutions offer extensive security features, with SSL-based end-to-end encryption fast becoming a checklist standard feature. • Most of the leading thin-client emulators and 3270/5250-to-HTML conversions offer AutoGUI capability to automatically rejuvenate the anachronistic user interface of mainframe and AS/400 applications. • The thin-client emulators, 3270/5250-to-HTML conversions, and the programmatic solutions enable the user interface of host applications to be extensively rejuvenated, with data from the host being augmented with data (including graphical data) from other sources. 13

APPLICATIONS FOR WEB-TO-HOST INTEGRATION • Thin-client emulators and 3270/5250-to-HTML conversion solutions are significantly less expensive than previous SNA/3270 emulation solutions. • The technology extends proven and established data center applications to the Web so that they can be used for E-commerce, online personal travel reservation, home banking, online investing, and online package/cargo tracking. IMMEDIATE USES FOR WEB-TO-HOST INTEGRATION TECHNOLOGY Web-to-host integration technology can be profitably used to synergistically bring together proven data center applications and new Web-based users in many different scenarios ranging from purely in-house intranetspecific situations to E-commerce initiatives that straddle the globe. Some of the most obvious and highest return-on-investment (ROI) uses for today’s proven Web-to-host integration technology include: 1. seamlessly extending the TCP/IP-based corporate intranet to displace the SNA/APPN-only or bridge/router-based multi-protocol network hitherto used to provide data center access 2. replacing existing remote access schemes (e.g., public frame relay network) used by field representatives and agents (e.g., insurance agents, travel agents, distributors) to reach data center resources with 3270/5250-to-HTML conversion-based access, across the Internet — thereby slashing remote access costs by 90 to 95 percent 3. migrating to thin-client solutions to realize significant savings related to upgrading and maintaining host access software on individual PCs and workstations 4. easily and cost effectively rejuvenating the dated and harsh user interface of host applications using the AutoGUI capability offered by Web-to-host solutions 5. easily developing new Web-centric applications by using 3270/5250to-HTML technology or one of the programmatic schemes to combine multiple existing host applications with some new business logic 6. enabling the general public to easily and transparently access certain data center applications (e.g., for home banking, online investing, or package/cargo tracking), over the Internet, with 3270/5250-toHTML conversion solutions — which moreover ensure that this access can be very user-friendly by enabling the user interface to be easily rejuvenated 7. dismantling existing private multi-protocol networks used to interconnect remote offices with corporate headquarters and using the Internet with Web-to-host integration technology, including DLSw, to very cost effectively and securely realize the necessary interconnection (the so-called Virtual Private Networking [VPN] technology, 14

Web-to-Host Integration: An Overwhelming Vote of Confidence readily available on most modern bridge/routers, is another way to use the public Internet as a means to realize intra-company networking requirements) BOTTOM LINE With Y2K now history, successful and synergistic Web-to-host integration is the next challenge facing MIS executives around the world. Web-to-host integration in effect melds the enormous and proven wealth of twentieth century data center resources with twenty-first century Web-centric computing that provides the public with unprecedented access to information and online applications. With Web-to-host integration, today’s mission-critical applications can be effortlessly extended to handle lucrative Internetbased E-commerce initiatives. Web-to-host integration technology has come of age. Today’s solutions are highly secure, scalable, stable, and proven. Household names like General Motors (GM), American Airlines (AA), Trans World Airlines (TWA), FedEx, Bank of America, and Del Monte Foods are already using various forms of Web-to-host solutions. There are no longer any valid excuses for not implementing Web-to-host integration. Web-tohost integration can slash networking costs and dramatically extend the reach of data center applications. Web-to-host technology, which is compelling and cogent, will prevail and play a pivotal role similar to that played by the PC in redefining and restructuring the future role of data center-centric computing. Note 1. i•nets is a generic, collective term to refer to all TCP/IP-centric, Internet technology inspired networks such as intranets, extranets, and the Internet itself.

15

Chapter 2

Knowledge Management on the Internet: The Web/Business Intelligence Solution Jason Weir

IN

THE TWENTY-FIRST CENTURY, YOU WON’T BE ABLE TO TELL WHERE

your enterprise ends and the World Wide Web begins. What’s more, you won’t really care — any more than you care now about which tabular scheme your computer’s operating system uses to store and retrieve data on your hard drive. That’s because the Web promises to transform the enterprise so that concepts like local storage and remote access will be so obsolete as to seem quaint. The Web will be so tightly integrated with the methods people use to access, analyze, and present corporate information that it’ll become increasingly inaccurate to talk about business intelligence applications. Rather, people will manipulate enterprise data in a rich business intelligence environment. Like a natural ecological system, a business intelligence environment will feature a variety of processes working in harmony to ensure the growth and enrichment of the system as a whole. In more concrete terms, business intelligence will evolve away from a model in which functionality is dumped on every desktop whether the user needs it or not, and where widely used data is needlessly duplicated across several personal hard drives when it could be shared and updated centrally. Users will gain access to server-based business intelligence services according to their needs. And crucial data in the environment — from full-fledged reports to simple executive buttons — will be stored and shared out centrally. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

17

APPLICATIONS FOR WEB-TO-HOST INTEGRATION The Web will not be just another networking pipeline; it will be an actual application platform on par with — indeed, seamlessly integrated within — major operating systems. Applications that run over the Web in this way are called thin clients. Microsoft’s next-generation operating system already incorporates the Web look and feel into its desktop interface so that everything — locally stored files, programs, and external Web sites — appear as links do in Web pages, and the globe-sprawling Web itself appears as an extension of the desktop. And what we now call fat business intelligence applications — featurerich, flexible, muscular programs that require at least some logic to reside on the desktop — will nevertheless use Web technology (like Java applets) and access Web-based resources as just another part of the enterprise view. That’s what’s coming in the twenty-first century. The question now facing the enterprise is simple — How do we build a business intelligence environment for the Web that will get us there? THE ENTERPRISE AND BUSINESS INTELLIGENCE To understand just what the Web means for business intelligence, you have to first look at how enterprises access, analyze, publish, and distribute corporate information. The complex task of extracting meaningful information from relational databases, multidimensional databases, and Relational Online Analytical Processing (ROLAP) servers into a point-andclick affair has been greatly simplified by modern technologies from a variety of vendors. For many Fortune 1000 companies, these business-oriented, high-performance repositories — deployed as data warehouses or, more recently, data marts, in the case of departmental repositories — have become the standard method of organizing data from an enterprise’s operations. They rely on these business intelligence systems to help cut costs, find new revenue opportunities, or change the enterprise and its processes to meet new challenges. CHALLENGES OF THE WEB While the Web’s promise for revolutionizing the enterprise is now well recognized, so too are some of its challenges. From a business intelligence perspective, Web technology is still evolving. Unaided, it can’t deliver the kind of functionality or performance required by the enterprise. From the standpoint of Information Technology (IT) professionals, the Web is a new frontier very different from the client/server landscape they know so well. Web technologies are still in flux, yet the onus is on IT to choose a Web/business intelligence solution that employs technology most likely to be relevant years down the road. In short, IT has to pick a winner when the 18

Knowledge Management on the Internet picking is tough. Research has shown that concerns about business intelligence over the Web break down into roughly three key themes: • the security of mission-critical (and expensive) corporate information systems • the scalability of Web-based systems when large volumes of information are exchanged between databases and Web clients • the burden of administration that may come with adopting Web systems that operate separately from existing business intelligence environments and may create a separate “stream” of Web-specific materials (reports and so on) that duplicates work done in the fatclient environment SECURITY When it comes to security, the Web suffers from a largely unjustified image problem. Because it was developed around open standards, the Web is thought to be wide open to all manner of electronic larceny — wiretapping, hacking, spoofing, and other security-compromising activities. Although such vulnerabilities may apply to poorly managed Web sites, a robust Web security toolkit exists nevertheless, consisting of public-key encryption, digital certificates, user-specific security “cookies,” secure sockets, and so on. However, these security measures were developed largely for uses of the Web — electronic commerce, for instance — that have nothing to do with business intelligence. In a typical, secure electronic-commerce transaction (the online purchase of a book using a credit card for example), the security measures applied are short-term and session-bound; once the customer sends an encrypted message containing his credit card number and the order is logged, the relationship between buyer and seller is over as far as the Web server is concerned. But in business intelligence environments, users are not customers who encounter corporate information on a one-time basis. Rather, they have an ongoing relationship with the enterprise’s data sources; they are individual users of data as well as members of one or more user groups, and they may fulfill organizational roles that cut across these groups. In a business intelligence environment, a marketing strategist is a single user but is also a member of the marketing group, with full access to marketing-specific reports, data tables, and data models. This member may also be a manager, with access to financial data appropriate for this organizational role, with a user, group, and role security profile that reflects various responsibilities within the organization. With its emphasis on encryption, Web-specific security cannot account for such continuous roles and relationships to enterprise data. 19

APPLICATIONS FOR WEB-TO-HOST INTEGRATION SCALABILITY This is one concern about the Web that is justified, at least where dataintensive, high-volume business intelligence requirements are concerned. Enterprise Web servers were really designed only to dole out Web pages — and when there are too many users knocking at their doors, even this simple task proves too much for most of them. Asking a Web server to handle a complex query with a results set of 5,000 records is like pumping data through a pinhole. What is more, a Web server alone does not have the smarts to handle something like a simple SQL query; it can hand off data processing to secondary processes using the Common Gateway Interface (CGI), but it then promptly forgets about the job until that secondary process returns results. This occasionally connected session is at odds with the needs of a business intelligence environment, which requires a persistent connection among client applications, processing services, and data sources. Persistence is key for any business intelligence session because the user needs an unbroken connection to services handling connectivity, query processing, security, and the like. A persistent session means faster performance of business intelligence tasks and much less chance of losing data. Conversely, data in an occasionally connected session is slowed and may even be lost as it’s passed from secondary processes through the Web server to the client. It’s rather like being served by absent-minded waitstaff who have to be constantly reminded who you are, where you’re sitting, and what you ordered. ADMINISTRATION From the point of view of many IT professionals, it looks like deploying business intelligence capabilities over the Web means reinventing the wheel. They have invested a lot of time and resources making the client/server model work for a sizable community of users. Now they have to use different technology — some of it pretty new and risky — to reach an even larger audience. Worries over administration break down into three categories: • Managing two environments — Just because the enterprise is serving a wider audience of users over the Web doesn’t mean it’s going to dump its fat-business intelligence clients. Many users will continue to need the expanded range of functionality that only resident client applications can provide. So if the Web/business intelligence solution isn’t compatible with the fat clients, IT now has two environments to manage, each with its own particular challenges, foibles, and infrastructure requirements. And if a fat-client user wants to use the Web as well, IT has to set up and maintain a second security profile. 20

Knowledge Management on the Internet • Managing two streams of content — If the environments are separate, so too are the materials created and stored in those environments — different report formats, different semantic layers, different query formats, and so on. This perpetuates the gap between fat-client users and the rest of the enterprise because it precludes sharing content among users with differing business intelligence needs and access privileges. From the point of view of the enterprise, a report is a report, and Web and fat-client users alike must view, interact with, and share the same content if the environment itself is to be enriched. • Installing and maintaining plug-ins — One way a vendor can really woo a crowd at a trade show is to build browser-specific plug-ins. These plug-ins look and feel like fat desktop applications because they are fat desktop applications, only they’re running inside a Web browser instead of within a normal desktop window. While such products make great parlor tricks, they suffer from some fatal flaws: — They’re big: in thin-client terms, 1.8 megabytes is the size of an aircraft carrier. — They’re platform-specific, meaning that you have to buy different plug-ins for different operating systems and even different versions of those systems. — They’re Web browser-specific, meaning the plug-in you buy for Netscape Navigator will not work on Microsoft Internet Explorer. — Finally, and what’s most important, these plug-ins must be installed individually on each desktop. Theoretically, you could ask your enterprise’s 2,000 users to install the plug-ins themselves. However, most IT professionals know that their user audience has different levels of technical sophistication — and they also know to whom the job of installing the plug-ins will fall. It’ll fall squarely on themselves. This type of desktop-centric deployment is a fat-client requirement: What’s gained by making it a Web client requirement too? What Does the Enterprise Need in a Web/Business Intelligence Solution? Clearly, it needs a Web solution that addresses the three crucial concerns discussed above. Such a Web solution must use a security model that promotes users’ ongoing relationships with corporate data as well as with other users, other teams, and other departments within the organization. It must be scalable, circumventing as much as possible the bottlenecks inherent in Web server technology. It must be seamlessly integrated with its fat-client counterpart and must serve users — regardless of platform — the same business intelligence content. Finally, such a Web solution must be able to balance these concerns about security, scalability, and ease of administration with Web users’ needs for powerful, meaningful access to the organization’s business intelligence resources. In short, what is needed is a well-managed Web/business intelligence solution. 21

APPLICATIONS FOR WEB-TO-HOST INTEGRATION So exactly what is needed to bring about such a solution? A discussion of some basic principles and emerging technologies that will enable a robust and effective Web-based business intelligence solution will help outline this.

FIRST PRINCIPLES If it’s going to succeed, a complex endeavor like a Web/business intelligence environment must start from first principles. These should be few in number but be applied without wavering. So before we get into all the technology, here are some first principles: • No gaps or stovepipes — The enterprise is an unbroken continuum of needs. A business intelligence environment should reflect this, leaving no gaps among user communities. In fact, Web functionality and fat-client functionality should overlap, so that learning and experience are applicable when users gain new levels of access. • Tight integration — Many organizations have spent the last five years reengineering their business processes, eliminating organizational stovepipes in favor of tightly integrated ones. Why should business intelligence vendors set back the clock by delivering technologies that separate users arbitrarily? • Common services, common data — The business intelligence systems that service this spectrum of needs must be holistic; Web (or thin) clients and fat clients should merely be different outlets for the same data. And as much as possible, thin and fat clients should be administered by the same logic and processing services. • Standard technologies — Budgets are not bottomless, and resources aren’t infinite. Technologies that become obsolete within two years are useless to the enterprise. So any Web-enabled business intelligence solution should employ technologies that are most likely to become industry standards with lasting value. With these first principles defined, a brief discussion of the technologies that enable Web-business intelligence is necessary.

THE BASIC ELEMENTS OF A WEB/BUSINESS INTELLIGENCE SOLUTION First, what elements are involved in a Web/business intelligence solution? In other words, what is the architecture of the environment? While vendors in the business intelligence space offer a variety of different packages, comprised of various components, most share the following services as part of their solution. 22

Knowledge Management on the Internet Web/Business Intelligence Server This is a server dedicated to housing the business intelligence solution for the enterprise. It may be completely dedicated to remote or occasionally connected users accessing the system via the Internet, or “balanced” with in-house activities. It houses the database and related applications required for the Web/business intelligence solution. Session Management Services These services control a Web client’s access to the server, track the use of various other services, detect whether the session has been discontinued, and clean up after the Web client has moved on. These services also monitor the performance of the session. File Management Services These include directory management, file naming, and file transfer services used by Web clients. For example, the directory management service maintains a list of materials (for example, reports and data models) that a Web users see in their business intelligence “portfolio.” Scheduling, Distribution, and Notification Services These services allow a Web user to schedule reports, queries, and information refreshes at a given time. Some tools enable event-based triggers, such as reports generated when inventory levels of a particular product drop below a certain level, or when sales of a specific product line increase to a given value. Notification can be sent via e-mail, by “push,” or channel, technologies, or by way of proprietary solution. Load Balancing Services Depending on the number of users, organizations may find it necessary to offload activity to alternate servers. That is, as more users share the same resource pool on a single server, the need to create duplicate, or mirrored, systems arises. Load balancing services manage the entire resource pool in a manner similar to what is called as a “clustered” environment. A cluster is two or more systems that essentially act as a single unit. Clusters are transparent to both end-users, and, for the most part, even administrators. Application Services These services are the brains of the operation. They enable simple Web browsers to become powerful front-end query and analysis tools. Some business intelligence vendors offer complete Web-enabled solutions that include browser plug-ins for end-user query, analysis, and reporting while others rely on proprietary applications to perform these tasks. 23

APPLICATIONS FOR WEB-TO-HOST INTEGRATION SUPPORTING TECHNOLOGIES Now that the basic elements of the Web-business intelligence solution have been discussed, a brief introduction to some of the technologies used to enable robust and effective solutions is useful. The Plumbing — CORBA, IIOP, and the Business Repository Consider all the different “audiences” to which the Web/business intelligence solution has to “play.” A typical enterprise has a mixture of Windows platforms (Windows 3.1, Windows 95, Windows NT) and perhaps some AS/400 and UNIX systems as well. To complicate matters, there are popular Web browsers offered by Netscape and Microsoft, with several different versions of each. Obviously, there cannot be a separate copy of information formatted for the different versions of end-user tools on each platform. Somehow, the server has to be able to talk to all of these clients and give them what they need in a format they can use. It’s rather like asking an interpreter at the United Nations to translate for several delegations at once — a daunting task even for the most accomplished linguist. What would make that beleaguered interpreter’s life a lot easier would be a universal translator. In essence, this is what CORBA does. CORBA The Common Object Request Broker Architecture (CORBA) is a specification that allows applications to: • Communicate with one another even though they’re running on different platforms. For instance, a UNIX version of the business intelligence server can service a Windows 95 desktop. • Move commonly used services, or objects, from the desktop to another location on a network — in this case, onto the business intelligence server. This is the heart of the distributed computing systems model that’s fast becoming adopted in enterprise software. Overseeing CORBA is the mandate of the Object Management Group (OMG), a coordinating body with a membership of over 750 companies. Established in 1989, the OMG promotes “the theory and practice of object technology for the development of distributed computing systems.” The group’s CORBA specification (now at 2.0) forms the standards by which Object Request Broker (ORB) vendors create their products. More specifically, the OMG defines the Interface Definition Language (IDL) and the Application Programming Interfaces (APIs) used to keep ORBs talking to one another. 24

Knowledge Management on the Internet Think of the ORB as middleware, but instead of mediating a connection between, say, a desktop client and a database, it sets up connections between the client and the application objects it needs located on a network. Thanks to the ORB, the client does not actually have to have that application object running on the desktop, nor does it need to know where the object actually is on the network. All the client needs to know is where the ORB is; the ORB in turn takes care of finding the object, passing on the client’s request, and returning the results of the object’s work to the client. All of this is transparent to the user. IIOP In a distributed object environment, ORBs need a robust, persistent pipeline through which to communicate. The Internet Inter-ORB Protocol (IIOP) is that pipeline. Adopted in 1994 as part of the OMG’s CORBA 2.0 specification, IIOP is designed for interoperability among objects. This means that if an object meets CORBA 2.0 specifications, it can, by definition, speak to any other CORBA 2.0-specified objects, even if they are made by different vendors. What’s more important to Web-enabled business intelligence, IIOP is a persistent communications protocol, a stark contrast to the HyperText Transfer Protocol (HTTP), the impersistent method Web servers use to take in and serve out data. Throughout a Web query session, the ORBs keep in constant touch with one another, exchanging user requests, returning results, and handling other background processes. Unlike a Web server, ORBs never hang up on one another as long as there’s a job to be done. In other words (going back to our plumbing metaphor), IIOP provides a robust pipeline in an environment where a user needs continuous access to services like database access or query processing. Java and XML Originally developed by Sun Microsystems as a platform-independent programming language for consumer electronics devices, Java has quickly become the defacto standard for extending the capabilities of the Web beyond the confines of HyperText Markup Language (HTML). Based loosely on C++ (the object-oriented programming language in which most desktop programs are coded), Java programs — called applets — are designed to run in any environment that supports a Java Virtual Machine (JVM). Microsoft and Netscape have fully integrated JVMs into their Web browser products. For Web/business intelligence purposes, Java provides: • A method of deploying application interfaces (data models, for instance) that are identical to the ones used by in-house applications. • The means to render data (results sets from queries, reports, and so forth) in much more flexible ways than is possible using HTML. 25

APPLICATIONS FOR WEB-TO-HOST INTEGRATION • A way to circumvent the impersistence of the Web server; Java applets can be “carriers” for ORBs, thus helping establish the IIOP pipeline between the Web client and the business intelligence server. This use of Java and XML means that Web/business intelligence solutions can be freed from the limited presentation abilities of HTML. For instance, HTML cannot deliver the WYSIWYG control required for reports because it cannot handle X–Y positioning, the ability to put a particular object (a graphic, chart, or block of text) in one precise spot on the page. Java and XML handle X–Y positioning perfectly so that reports look exactly the same whether viewed over the Web or in a fat client. CONCLUSION In summary, by combining emerging technologies like CORBA, IIOP, Java, and XML with robust Web-enabled business intelligence tools, Web/business intelligence solutions offer organizations a superior weapon in today’s competitive global economy. Companies can gain real competitive advantage by moving and transporting the proven effectiveness of inhouse decision support systems to the Web.

26

Chapter 3

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative James A. Senn

EXCHANGING

BUSINESS TRANSACTIONS ONLINE THROUGH ELECTRONIC

document interchange is a well-understood practice. However, EDI’s potential is limited by the inability of millions of companies to participate. That will change as the projected impact of Internet EDI means every company can become a trading partner. The corporate mandate to “link up or lose out,” increasingly common in business, has led many firms to develop interorganization systems whereby buyers and sellers share information electronically. These powerful systems are among the most important forces in business. Many have played a pivotal role in changing the business strategies and operational tactics employed in commerce and are causing the proportion of commerce conducted online by business to grow. Electronic data interchange (EDI) has been the underlying technology of choice for implementing interorganization systems. Yet only a fraction of the firms who could benefit by online commerce are using EDI. Thus the full potential of interorganization systems and electronic commerce will be constrained until a substantially larger proportion of businesses is able to participate.

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

27

APPLICATIONS FOR WEB-TO-HOST INTEGRATION IMPACT OF EDI Electronic data interchange is a computer-to-computer electronic communication method whereby trading partners (e.g., hub organizations and their spoke customers and suppliers) in two or more organizations exchange business transactions. The transactions consist of documents in structured formats that can be processed by the recipient’s computer application software (Exhibit 3-1). GROWTH OF EDI The origin of EDI in the late 1970s opened the way for business to conduct a greater portion of the routine buyer-seller business activities online. Sensing the opportunity to reduce paperwork, automate key transactionhandling activities, reduce cycle time, and cut inter- and intra-industry coordination costs, the early adopters quickly gravitated toward EDI. Transaction formats were established within the United States, followed rapidly by the emergence of international standards. Expectations were high that EDI would become the way of handling buyer/seller business transactions. EDI has changed the landscape of business, even triggering the redefinition of entire industries. Well-known retailers, such as The Home Depot, Toys R Us, and Wal-Mart, would operate very differently today without EDI, for it is an integral and essential element of their business strategy. Thousands of global manufacturers, including Proctor and Gamble, Levi Strauss, Toyota, and Unilever have used EDI to redefine relationships with their customers through such practices as quick response retailing and just-in-time manufacturing. These highly visible, high-impact uses of EDI by large companies have been extremely successful.

Exhibit 3-1.

28

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative LIMITATIONS OF EDI Despite the tremendous impact of EDI among industry-defining leaders, the current set of adopters represents only a small fraction of potential EDI users. In the United States, where several million businesses participate in commerce every day, fewer than 100,000 companies have adopted EDI. In reality then, most businesses have not benefited from EDI or interorganization systems. Extensive interviews with company leaders revealed five principal reasons: • Significant Initial Resource Commitment — Start-up costs associated with EDI implementation accrue from the need for software, network interconnections, new personnel, and typically contracting with an outside network service. Estimates for a hub company wishing to pursue EDI vigorously range from $100,000 to $250,000 just to get underway. The translation software needed to transform company data from internally used formats to the structure of standard industry transaction sets often requires an investment of $100,000. Hub companies are not the only ones accruing startup costs. Their trading partners also face expenses when they respond to EDI mandates, for they must purchase translators, augment communications links, and often add staff. It is repeatedly evident that hub and spoke companies both estimate technology costs better than startup staffing requirements. Frequently firms learn that true staffing requirements turn out to be more than double their original estimates. • Restructuring Business Processes — In many firms, EDI touches every major business process — procurement, inventory management, manufacturing, order fulfillment, shipping, invoicing, payments, and accounting — and thus cuts across an entire company’s practices. The business process changes needed to respond to a hub company’s EDI requirements can thus disrupt well-ingrained practices. Since different hub firms often insist on unique procedures that fit their operations, a trading partner may ultimately have to support multiple versions of a specific process. • Start-up Challenges — The challenge of implementing EDI requires months, not days, of startup efforts. Selecting and agreeing on the format of transaction sets, defining performance expectations, and negotiating legal matters not only taxes the best intentions of both parties, but can burn up hours of staff time. • Use of Private Networks — Private value-added networks (VANs), constructed and operated by third parties, are used by most EDI trading partners as the principal means of exchanging transactions. VANs are useful to both hub and spoke companies because they provide the essential communication link. Yet neither company is required to invest in or maintain an EDI network. Each can use the VAN on a pay-as-yougo basis. However, if a dominant trading partner specifies use of a 29

APPLICATIONS FOR WEB-TO-HOST INTEGRATION particular VAN, or when VANs will not agree to exchange transactions with one another, companies may have no choice but to work with multiple service providers. The result is extra expense, added process hassles, and sometimes multiple translation packages. • EDI Operating Cost — Although EDI often reduces internal transaction costs, the process itself creates new expenses (beyond startup costs). If EDI volume is high, the ongoing transaction costs paid to a VAN accumulate to be a large expenditure, exceeding $100,000 annually for high volume users. Therefore, it is not surprising that heavy EDI traders are seeking ways to reduce these expenses for themselves, their current trading partners, and for potential new spoke companies. EXPANDING EDI’S IMPACT The preceding concerns suggest that traditional EDI, relying on formal transaction sets, translation software, and value-added networks, is not the enabling technology needed for the long-term solution. They are obstacles to expanding EDI’s impact. For the proportion of commerce conducted electronically to grow more emphatically, four requirements must be met: 1. Enable more firms to use EDI. Across industries, the two largest trading partner segments not using EDI are (1) small business buyers and suppliers, and (2) important large and midsize companies who place few orders (regardless of their value) with a hub company. Firms in each group have shunned EDI, unable to justify the investment or convince themselves of the payoffs. Yet many managers in these firms acknowledge that lower costs would enhance EDI’s appeal. 2. Encourage full integration of EDI into trading partner business processes. Paper and dual processing is still the norm for a substantial number of spoke company trading partners. Although they may accept EDI transactions, they do not process them, choosing instead to transfer the incoming transactions to paper and subsequently reentering the details into their own system. These firms have not developed the application-to-application interconnection that would enable them to share critical sales and inventory data electronically. 3. Simplify EDI implementation. The time it takes to bring new partners up to speed is considered excessive, further limiting EDI penetration. Hence, both hub and spoke companies seek more rapid, inexpensive implementation alternatives that will reduce the average implementation time from months to days. 4. Expand online information exchange capabilities. Because EDI has shown the benefits of electronic commerce to be substantial, it is not surprising that participating companies frequently seek to extend their capabilities to exchange more business information online. For example, hub and spoke companies frequently request price lists, catalogs, and the capability to check supplier inventory 30

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative levels available online. EDI’s current structure of transaction sets and formatted standard business documents does not facilitate such a capability. EDI OVER THE INTERNET There is little question that the Internet, as one lane of an emerging global information highway, is a growing force influencing strategy for all forms of electronic commerce.1 When considered as a channel for EDI, the Internet appears to be the most feasible alternative for putting online business-to-business trading within the reach of virtually any organization, large or small. There are five reasons for hub and spoke firms to create the ability to exchange transactions over the Internet: • The Internet is a publicly accessible network with few geographical constraints. Its greatest attribute, large-scale connectivity (without the demand to have any special company networking architecture) is a seedbed for growth of a vast range of business applications. Only a few of the potentially attractive applications capitalizing on the Internet’s capabilities and features for business-to-business exchanges have even been conceived to date. • The Internet’s global internetwork connections offers the potential to reach the widest possible number of trading partners of any viable alternative currently available. • Powerful tools that make it feasible to interconnect traditional business applications to the Internet with a minimum of challenges are emerging rapidly. No end to this trend is in sight. • Using the Internet to exchange EDI transactions is consistent with the growing interest of business in delivering an ever-increasing variety of products and services electronically (i.e., via electronic commerce), particularly through the World Wide Web. • Internet EDI can complement or replace current EDI strategies. The three principal channels for Internet EDI include the World Wide Web, FTP exchanges, and electronic mail (see Exhibit 3-2). WWW EDI The combination of World Wide Web (WWW or simply the “Web”) and graphical browsers are the key reasons the Internet has become so easily accessible to the vast array of business and non-business users. This combination can do the same for EDI. Exchanging EDI transactions using the World Wide Web (i.e., Web EDI) capitalizes on its document format as the means for creating on-screen templates (see Exhibit 3-3) into which trading partners enter transaction details. Using this method, any standard business form (e.g., requests for quotation, purchase orders, or purchase order changes) can be displayed as a template. 31

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Channel WWW EDI

Description Using an ordinary browser, trading partner pulls down EDI transaction templates from a designated WWW server operated by: Value added network providers, Value added Internet service providers, or Hub companies.

FTP EDI

EDI transactions are accumulated as they are entered at the spoke company. Periodically the spoke company transmits the batch file to the hub company using the Internet’s File Transfer Protocol.

E-Mail EDI

EDI transactions are inserted into an electronic mail message and transmitted over the Internet in the same way as all other e-mail.

Exhibit 3-2.

The three principal channels for Internet EDI.

Exhibit 3-3. Purchase order template.

HTML is the language of the WWW and therefore the means by which EDI templates are constructed, displayed, and processed. HTML allows designers to format each on-screen template in an easy-to-use layout and, if desired, even duplicate the design of paper forms. Color, image, and multimedia features may also be included to enhance appearance and usability. 32

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative Completed Web EDI forms are transmitted to the hub company over the Internet. Its route and any intermediate processing depend on which Web EDI alternative is used: by way of value-added networks, using Internet value-added service providers, or direct to hub company servers. WEB EDI USING VALUE-ADDED NETWORKS Sensing both opportunity and threat from the Internet and Web EDI, all value-added network providers (VANs) will roll out Web EDI services, with similar capabilities.2 Although individual VANs will undoubtedly add special features, this method will function as follows: Users at spoke companies will access the designated VAN’s Web site (by specifying the appropriate uniform resource locator (URL) — its Web address) where the hub company’s transaction templates are maintained. The user’s browser pulls down the template onto the desktop to enter transaction details. A completed Web template is returned, via the Internet, to the VAN’s Web server where the document’s HTML code is translated into the EDI transaction format required by the hub company (see Exhibit 3-4). Then it is transmitted over the VAN to the hub company site where it is received and processed like any other EDI document. Trading partners benefit by having a facility, at very low cost, for transmitting documents electronically without having to acquire or maintain special EDI software. Since most firms already have Internet access for other purposes, the intrusion into ordinary work processes is minimal (see Exhibit 3-5).

Exhibit 3-4. Internet EDI using a VAN.

33

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Advantages • No special software is required if a trading partner is already using the Internet. • Converting new users to Internet EDI is relatively rapid when since the transaction is initiated using the familiar World Wide Web browser or e-mail formats. • Submission of EDI transactions is template-driven whereby trading partner staff members fill in on-screen templates using a World Wide Web browser. • Hub companies can easily change business rules by adjusting EDI templates or altering translation and processing routines on their server. • If desired, the convenience and safeguards offered by value-added service providers can be incorporated into Internet EDI. • VAN can build and maintain on-screen templates and server sites, freeing hub company staff. • Internet EDI can be integrated with traditional EDI as transactions are received from VAN. Exhibit 3-5.

Disadvantages • Transmission delays over the Internet are not predictable. • If VANs are not involved, transaction pickup and delivery actions are not logged nor are receipt notifications generated. • If VANs are involved, charges for their services are incurred. I

I

I

• If a WWW front-end is not used with the FTP alternative, it is necessary to design and develop of a client/server front-end to create the transaction. • Compared to other Internet EDI methods, the FTP alternative requires additional steps to accumulate and transmit batch files. I

Advantages and Disadvantages of Internet EDI.

The hub company benefits in three ways: • It can use the simplicity of the WWW interface to induce more trading partners to initiate business transactions electronically. • It can add new trading partners while sustaining current electronic relations with high volume trading partners already accustomed to EDI. • It gains the capability to integrate standard transaction formats from both sets of companies into its electronic transaction processing stream. WEB EDI USING INTERNET VALUE-ADDED SERVICE PROVIDERS If the hub company chooses, Web EDI templates can be maintained by an Internet value-added service provider (VASP), e.g., America Online and CompuServe. With this alternative, the trading partner pulls down EDI forms from the VASP’s server, enters transaction details, and returns them to the service provider who in turn transmits them to a VAN for translation and forwarding. The remainder of the process is the same as above. 34

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative WEB EDI USING HUB COMPANIES SERVERS A hub company may also choose to bypass intermediaries entirely and maintain its own Web EDI server when following this method. A trading partner will point the browser at the hub’s Internet URL to pull down the appropriate transaction template. When completed, the template is returned over the Internet to the hub’s server where translation from HTML and processing occurs as described above. The hub company must include in its Web server the capabilities to notify trading partners of the receipt and acceptance of transactions, a process that is normally an integral part of VAN services. FTP-BASED EDI A second Internet EDI option uses the File Transfer Protocol (FTP) capability. FTP EDI, which transfers entire files of transactions at one time, is useful when the sequence of collecting and sending batches of electronic transactions to hub companies is repeated frequently (see Exhibit 3-6). In the health care industry, for example, the claims submission process consists of health care providers (hospitals, physicians, and laboratories) who submit batches of claims forms periodically to insurers, and sometimes government agencies. With FTP EDI, providers can submit their claims, batched and in electronic form, over the Internet. Using FTP EDI, a trading partner first prepares an individual EDI transaction set by filling in an electronic template on the computer screen. (In a client/server or LAN environment, multiple staff members are able to prepare transactions simultaneously.) As details are entered, they are formatted according to pre-determined EDI specifications. When the transaction is completed, it is added to the batch that is accumulated at the trading partner’s site. Periodically the batch is readied for transmission. The transaction sets are encrypted for privacy, if desired, prior to transmission. Digital signatures3 may also be added, giving the recipient a means of authentication. Then the transaction file is transmitted over the Internet, using FTP, to the recipient’s server. The recipient EDI file first performs the authentication (if desired), normally on a server outside the recipient’s firewall. This protects the integrity of the hub site in the event the file has been altered or tampered with in any way prior to its arrival. Encrypted EDI files may be decrypted (i.e., returned to their original transaction set format for processing) on either side of the firewall. Once these steps are completed, processing of the EDI transaction can get underway. 35

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Exhibit 3-6. Internet EDI Using FTP.

MIME AND E-MAIL EDI The third Internet EDI alternative uses electronic mail. On the one hand, value-added network service providers have been augmenting their support of EDI using e-mail (via the X.435 mail standard4). At the same time, the Internet community is also aggressively developing another e-mail capability. Multipurpose Internet Mail Extensions (MIMEs) specify how EDI transactions can be sent as enveloped messages (Exhibit 3-7) using Internet Simple Mail Transport Protocol (SMTP), the principal method for sending and receiving e-mail over the Internet.5 Trading partners can thus transmit messages containing EDI documents over the Internet to the mailboxes of hub companies. Transmission and arrival will occur in much the same way as any other e-mail message, with the EDI information embedded in the message. The methods of identifying EDI transaction sets within a MIME e-mail message are under development by the EDI working group of the Internet Engineering Task Force (IETF-EDI). The work of the task force will be a principal factor in the emergence of E-mail EDI. Hence, it is highly plausible that other business applications will be expanded to accept or generate e-mail messages containing EDI transactions. 36

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative

Exhibit 3-7. Internet EDI using MIME e-mail.

INTERNET EDI AND ELECTRONIC COMMERCE STRATEGY What does Internet EDI mean for business? It’s increasingly evident that broadening the view of EDI is consistent with the creation of an electronic commerce strategy. Furthermore, incorporating the right set of objectives into that strategy can unlock a range of benefits even as it triggers new business opportunities. BROADENING THE VIEW Internet EDI’s features should be treated as more than just a new generation of electronic data interchange. They can stimulate the creation of a broader array of services as well as trigger new business strategies even as they hold a key to increasing the number and characteristics of participating trading partners. Managers who view Internet EDI as no more than a technology foundation for online exchange of transactions will likely overlook important opportunities and face loss of business. Rather than a form of technology, Internet EDI is a new channel for conducting business. Therefore, it must be incorporated into an overall electronic commerce strategy. COMPONENTS OF EDI STRATEGY At a minimum, an EDI strategy should include five objectives. First, with cost and implementation barriers reduced, and multiple channels of interaction now available, companies should seek to use Internet EDI as a vehicle for bringing as many trading partners online as possible. The benefits — reduced cycle time, improved coordination mechanisms, elimination of paper documents, and more — will accrue to both hub and spoke companies. Second, company objectives should include revenue generation, not just cost savings. Key features that make electronic commerce attractive to a hub company’s upstream suppliers can also be beneficial to its downstream buyers and thus can lead to new revenue. These features can be an integral component in growth and market building strategies. 37

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Since the exchange of documents electronically typically touches every major business process, implementation of Internet EDI should trigger renewed interest in cross-function redesign of business processes. Company intranets and extranets can readily be components of Internet EDI as well as embedded in internal processes. When online documents are evaluated with an eye toward simplifying business processes, the gains of deploying information technology in innovative ways are not only possible, but liberating. The result may transcend different business processes to the creation of new business models. Fourth, companies should treat the Internet as a new front-end to their business. The same features that are attractive for enhancing EDI, including large-scale connectivity, wide geographic reach, a document paradigm facilitated by HTML, and the client/server structure mean the Internet can be integrated with current and planned mission-critical business applications and back-end support systems. The comfortable, multimedia interface of the WWW offers front-end opportunities that are at best challenging to create through traditional means. Finally, companies should capitalize on the desirability of electronic payment and receipt. Streamlining invoicing and payment processing was responsible for triggering the business process reengineering revolution.6 Companies quickly saw the benefits of not having to deal with traditional payment systems. It’s time to realize that when business-to-business transactions can be created online they can also be settled online. Removing the two principal roadblocks — the mindset of trading partners and the commitment of financial institutions — will facilitate online settlement practices. SUMMARY There is little doubt that Internet EDI will become the method of choice for conducting business electronically, paving the way for the bulk of business-to-business EDI to be conducted over the Internet. Whether a company is large or small, the exchange of business information online will be an integral component of business strategy. Companies who fail to capitalize on Internet EDI are likely to miss opportunities even as they risk their current successes. Notes 1. Senn, James A., “Capitalizing on Electronic Commerce,” Information Systems Management. 13,3 (Summer 1996) pp. 15-24. 2. Prototypes of VAN EDI services suggest that companies seeking to use this form of Web EDI will pay a modest startup fee to the VAN and a monthly subscription fee entitling them to a specified number of transactions. Additional transactions will be billed on a per item basis. VANs will also charge hub companies to prepare and post each transaction template to the Web site.

38

Expanding the Reach of Electronic Commerce: The Internet EDI Alternative 3. A digital signature is an electronic code or message attached to a file or document for the intention of authenticating the record. It is attached, by software, in such a manner that if the contents of the message are altered in any way, intentional or accidental, the digital signature is invalidated. Laws governing the creation and use of digital signatures are emerging as business and government recognize they are essential to the growing reliance on electronic commerce. 4. In the 1980s, the X.400 standard was created to facilitate the exchange of e-mail messages between different systems. It has become the global e-mail standard. During the 1990s, a subset of the X.400 standard, designated X.435, was created as a standard for distinguishing EDI transaction sets within an ordinary e-mail message. 5. SMTP, which provides a common specification for the exchange of e-mail messages between systems and networks, is the method most users unknowingly rely on when transmitting mail over the Internet. 6. Hammer, Michael, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review. 68,4 (July-August 1990) pp. 104-112.

39

Chapter 4

Business-to-Business Integration Using E-commerce Ido Gileadi

NOW THAT MANY OF THE FORTUNE 1000 MANUFACTURING COMPANIES have implemented ERP systems to streamline their planning and resource allocation, as well as integrate their business processes across the enterprise, there is still a need for integration with the supply chain. To reduce inventory levels and lead times, companies must optimize the process of procurement of raw materials and finished goods. Optimization of business processes across multiple organizations includes redefining the way business is conducted as well as putting in place the systems that will support communication between multiple organizations each having their own separate systems infrastructure and requirements. This type of business-to-business electronic integration has been around for some time, in the form of Electronic Document Interchange (EDI). EDI allows organizations to exchange documents (e.g., purchase orders, sales orders etc.) using standards such as X.12 or EDIFACT and value-added networks (VANs) for communication. The standards are used to achieve universal agreement on the content and format of documents/ messages being exchanged. EDI standards allow software vendors to include functionality in their software that will support EDI and communicate with other applications. The VAN is used as a medium for transferring messages from one organization to the other. It is a global proprietary network that is designed to carry and monitor EDI messages. The EDI solution has caught on in several market segments but has never presented a complete solution for the following reasons: • High cost for set-up and transactions. Smaller organizations could not afford the cost associated with set-up and maintenance of an EDI solution using a VAN. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

41

APPLICATIONS FOR WEB-TO-HOST INTEGRATION • EDI messages are a subset of all the types of data that organizations may want to exchange. • EDI does not facilitate an online access to information, which may be required for applications such as self-service. With the advance of the Internet both in reliability and security and the proliferation of Internet based E-commerce applications, E-commerce has become an obvious place to look for solutions to a better and more flexible way of integrating business to business processes. The remainder of this chapter discusses a real-life example of how internet and E-commerce technologies were implemented to address the business-to-business integration challenge. BUSINESS REQUIREMENTS The business requirements presented to the E-commerce development team can be divided into three general functional area categories: • general requirements • communicating demand to the supply chain • providing self-service application to suppliers General requirements included: • 100 percent participation by suppliers — the current EDI system was adapted by only 10 percent of suppliers • minimize cost of operation to suppliers and self • maintain high level of security both for enterprise systems and for data communicated to external organizations • utilize industry standards and off-the-shelf applications wherever possible; minimize custom development • supplier access to all systems through a browser interface Demand requirements included: • send EDI standard messages to suppliers –830: Purchase Schedule –850: Purchase Order –860: Purchase Order Change • provide advance notice of exceptions to demand through exception reports Exhibit 4-1 describes the flow of demand messages (830,850,860, exceptions) between the manufacturer and supplier organization. The demand is generated from the manufacturer ERP system (Baan, SAP etc.), it is then delivered to the supplier through one of several methods to be discussed later. The supplier can load the demand directly into their system or use the supplied software to view and print the demand on a PC. The supplier 42

Business-to-Business Integration Using E-commerce

Exhibit 4-1. Demand flow.

can then produce an exception report, indicating any exception to the accepted delivery of goods. The exception report is sent back to the manufacturer and routed to the appropriate planner. The planner can view the report and make the necessary adjustments. Self-service application requirements included: • ability for suppliers to update product pricing electronically, thereby ensuring price consistency between manufacturer and supplier • provide online access with drill-down capabilities for suppliers to view the following information: –payment details –registered invoices –receipt of goods details –product quality information TECHNICAL REQUIREMENTS The technical solution had to address the following: • transport EDI messages to suppliers of various levels of computerization • provide complete solution for suppliers that have no scheduling application • support small and large supplier organization seamlessly • provide batch message processing and online access to data • provide security for enterprise systems as well as data transmission • utilize industry standards and off-the-shelf products 43

APPLICATIONS FOR WEB-TO-HOST INTEGRATION The technical requirements can be divided into three categories: • general requirements: –low cost –low maintenance –high level of security –industry standards • batch message management • online access to enterprise information In reviewing the three main categories of technical requirements, it is apparent that one needs a product to support message management (EDI and non-EDI) and same or other product to provide online access. The selected products must possess all the characteristics listed under general requirements. E-COMMERCE PRODUCT SELECTION Selection of E-commerce products to construct a complete solution should take the following into consideration: • What type of functionality does the product cover (online, batch, etc.)? • Is the product based on industry standards or is it proprietary? • Does the product provide a stable and extensible platform to develop future applications? • How does the product integrate with other product selections? • What security is available as part of the product? • What are the skills required to develop using the product, and are these skills readily available? • Product cost (server, user licenses, maintenance) • Product innovation and further development • Product base of installation • Product architecture The E-commerce team selected the following products: • WebSuite and Gentran Server from Sterling Commerce. This product was selected for handling EDI messages and communication EDI and non-EDI messages through various communication mediums. This product provides the following features: –secure and encrypted file transfer mechanism –support for EDI through VANs, Internet, and FTP –browser operation platform using ActiveX technology –simple integration and extendibility through ActiveX forms integration –simple and open architecture 44

Business-to-Business Integration Using E-commerce –easy integration with other products –eDI translation engine • Baan Data Navigator Plus (BDNP) from TopTier. This product was selected for online access to the ERP and other enterprise applications. The product has the following main features: –direct online access to the Baan ERP database through the application layer –direct online access to other enterprise applications –integration of data from various applications into one integrated view –hyper Relational data technology allowing the user to drag and relate each item data onto a component, thereby creating a new more detailed query providing drill-down capabilities –access to application through a browser interface –easy-to-use development environment Both products were just released at the time we have started using them (Summer 1998). This is typically not a desirable situation as it can extend a project due to unexpected bugs and gaps in functionality. Product choice was based on their features, the reputation of the companies developing the products and the level of integration the products provided with the ERP system already in place. E-COMMERCE SOLUTION Taking into account the business and technical requirements, a systems architecture was put together that provided a business and technical solution. On the left side of Exhibit 4-2 are the client PCs located at the supplier’s environment. These are standard Win NT/95/98 running a browser capable of running ActiveX components. Both the applications (WebSuite and TopTier) are accessed through a browser using HTML and ActiveX technologies. As can be seen in the diagram, some suppliers (typically the larger organizations) have integrated the messages sent by the application into their scheduling system. Their system loads the data and presents it within their integrated environment. Other suppliers (typically smaller organizations) are using the browser-based interface to view and print the data as well as manipulate and create exception reports to be sent back to the server. Communication is achieved using the following protocols on the internet: • HTTP, HTTPS — for delivery of online data • Sockets (SL), Secure Sockets (SSL) — for message transfer

45

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Exhibit 4-2. Technical architecture.

All traffic enters the enterprise systems through a firewall for security. Security is discussed in the following section. On the enterprise side, the client applications first access a Web server. The Web server handles the HTTP/HTTPS communication and invokes the server-side controls through an ASP page. The online application (TopTier) intercepts the HTTP/HTTPS communication address to it and interprets the query. It then provides a result set and integrates the result set with an HTML template to be sent back to the client PC as an HTML page. The online access application communicates with the ERP application through the application API or through ODBC. The message management application (WebSuite) communicates to the message queue using server-side ActiveX controls and FTP to send and receive files between systems. The message management application communicates with the ERP and other enterprise applications using a set of processes that can read and write messages to a shared mounted disk area. The above system architecture supports a mechanism for transferring messages in a secure and reliable fashion as well as providing online access to data residing in the enterprise systems — all through a browser interface with minimal requirements from the supplier and minimal support requirements.

46

Business-to-Business Integration Using E-commerce SECURITY There are two categories of security that must be handled: • enterprise systems security from outside intrusion • data security for data communicated over the Web Security for the enterprise is intended to prevent unauthorized users from accessing data and potentially damaging enterprise systems and data. This is handled by various methods that are far too many to have a meaningful discussion in this chapter. One can review the steps taken to secure the system on this project; these are by no means the only or the complete set of measures that can be taken. In addition each organization may have different security requirements. This project involved the following: • use a firewall that provided the following: –limitation on IP and PORT addresses –limitation on protocols allowed (HTTP, HTTPS, IP) –user authentication at the firewall level –abstraction of Server IP address • authentication –front-office application layer –back-office application layer –operating system layer –firewall layer • domain settings –Web server machine is not part of the enterprise domain –Web server machine has IP access to other servers Data security is required to protect the information that is transferred between supplier and manufacturer over the public domain of the Internet. The intent is to secure the data from unauthorized eavesdropping. There are many methods to protect the data; these methods can be grouped into two main categories: • Transferring data through a secure communication channel (SSL, HTTPS). This method utilizes: –authentication –certificates –encryption • Encryption of data. This method is typically used in conjunction with the previous method, but can be used on its own. There are various encryption algorithms available. The encryption strength (cipher strength), which can be defined as how difficult it would be to decrypt encrypted data without the keys, can vary and is designated in terms of number of bits (i.e., 40bit, 128bit, etc.). This project incorporated 47

APPLICATIONS FOR WEB-TO-HOST INTEGRATION the use of Microsoft Crypto API, which is supported both by the Web server (IIS 4) and by the client Browser (IE 4). The cipher strength selected was 40bits to allow non-U.S. and Canada access to the application. 128bit cipher strength is not available for browsers used outside the United States and Canada. CONCLUSION Manufacturing organizations striving to reduce inventory levels and lead-times must integrate business processes and systems with their supply chain organization. E-commerce applications utilizing the Internet can be used to achieve integration across the supply chain with minimal cost and standard interfaces. When implementing E-commerce applications, it is recommended to select application that can be used as an infrastructure to develop future business solutions to address new requirements. Selecting applications that provide technology solutions with a development platform rather than applications that provide an integrated business solution will provide a platform for development of future business applications as the use of E-commerce proliferates through the organization.

48

Chapter 5

Web-to-Information-Base Access Solutions Marion G. Ceruti

THE PURPOSE OF THIS CHAPTER IS TO ASSIST MANAGERS OF INFORMATION systems programs who are interested in successful implementations of World Wide Web technology to access information bases, including databases and knowledge bases. This chapter also describes research efforts to extend the present capabilities in Web-based access. The Web has emerged as a form of data access middleware in some applications because of its efficiency and generality, owing to a common data transfer protocol.3 (See, for example, References 2, 7, 8.) It is a key component in meeting data and knowledge access requirements. It also has become a tool for software reuse.8 For example, databases, knowledge-base development tools, data mining tools, images, textual documents, standards, and a variety of software tools are accessible on the Web3 to any user with a Web browser, which is defined as a client software that accesses and displays Web pages, such as Netscape Communications Corp.’s Navigator.5 This chapter describes case studies of Web applications in systems and research programs sponsored by the Department of Defense (DoD), and by universities as well as Web-based access products and services developed in private industry. It describes technology that military, academic, and commercial systems need to address information access requirements of the future. For example, as the tactical emphasis in the DoD shifts from platform-centric toward network-centric warfare, the issues in network utilization, the interoperability of new and legacy systems, and the reuse that the networks enable become more significant. DoD laboratories and agencies are aware of the advantages in information systems access over the Internet and have been developing programs for various purposes, all of which are aimed at sharing either data or knowledge among service components.8 Similarly, many advances in information access have been made in academia and industry, some of which are described below. Maurice Frank provides a good discussion5 of various techniques and products that enabled Web browsers to exchange data with databases as of 1995. It covers commercial Web-to-database interface products of the 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

49

APPLICATIONS FOR WEB-TO-HOST INTEGRATION leading vendors of Relational Database Management Systems, such as Oracle Corp., IBM, Sybase Inc., and Informix Corp., as well as the products of several third-party vendors. The chapter also discusses Web-based database integration using the Common Gateway Interface (CGI), and presents some additional information that has become available since then. Web solutions that enable information access are described below in four case studies: Web-based data access, Web-based metadata access, Web-based knowledge access, and network-centric warfare. The second and third case studies include multiple examples of Web-based access, whereas the first and fourth studies describe single examples. CASE STUDY 1: METEOROLOGICAL AND OCEANOGRAPHIC WEB-BASED DATA ACCESS A long-standing problem in the DoD is to provide uniform and efficient access to all users who need to view and use databases and data objects. Version control for data sets that are sent from data centers to various sites, both to headquarters and to deployed units, has been a problem because by the time the last site receives the data set, it is either out of date or different from the version received at the first site. This is also an inefficient and labor-intensive way to distribute data. Keeping all units updated with the same data simultaneously was not tractable or affordable before the use of networks. This situation is changing because one of the most user-friendly developments in the area of data access for the database community in general has been the use of the Web. The Navy systems that provide Meteorological and Oceanographic (METOC) data will be used as examples in this discussion. (See, for example, Reference 13). Because of the dynamic nature of these environmental data, finding a solution to the problem of immediate access to timely, accurate, and consistent information is very important. For the METOC users in particular, this access solution is via the Joint METOC Viewer (JMV). (See, for example, Reference 10.) JMV is a multiplatform, client/server application suite, the design of which was based on the user interface design of the Navy Oceanographic Data Distribution System.10 Authorized DoD users (both Navy and non-Navy) can access METOC data from most geographic locations. The Web-accessible data on JMV is divided into two groups: data that can be transferred to another platform and data available in a read-only mode. Using JMV, METOC numerical data and products are available for downloading by geographic region. This data includes surface pressures and temperatures. Still a wider variety of data is available for display as images in windows on the screen. For example, the user can display profiles and crosssections of three-dimensional atmospheric and oceanographic data.10 50

Web-to-Information-Base Access Solutions The Web has the advantage of being independent of the hardware platform because network browsers, using a common Hypertext Markup Language (HTML) protocol for net access, are available for many platforms.10 (See also, Reference 5). Web-based access to METOC data solves the problem of disseminating batch data sets to sites, since any site can view, and in some cases download, the data on the Web. It also solves data storage and throughput problems that were introduced when data resolutions increased from a 2.5-degree grid spacing to a 1.0-degree grid spacing. The efficiency of JMV has provided the DoD with not only enhanced capabilities, but also substantial cost savings.10 DoD users can access the Naval Pacific METOC Center directly. Access to JMV for non-DoD U.S. government users is via the National Weather service. Information on JMV and the data to which it provides access is available at Web sites with the following URLs: • • • • •

http://152.80.56.202/faqs/faq_jmv_gen.html http://cnodds.nws.noaa.gov/jmv_man/jmvumtoc.htm http://www.nrlmry.navy.mil/~neith/Sigmet.html http://www.nlmoc.navy.mil/newpage/navigate2.html http://www.fnmoc.navy.mil/

CASE STUDY 2: WEB-BASED METADATA ACCESS FOR MODELING AND SIMULATION DoD’s Modeling and Simulation Resource Repository Modeling and simulation efforts in the DoD have grown in proportion to the shrinking defense budget because it is much more economical to run a simulation prior to field tests than it is to conduct numerous preliminary and costly field tests without the benefit of the information derived from modeling and simulation. Modeling and simulation is so important to the DoD that the Defense Modeling and Simulation Office (DMSO) has established a data repository known as the Modeling and Simulation Resource Repository (MSRR). The DMSO charter is to develop a common technical framework for modeling and simulation that includes a common, high-level simulation architecture and conceptual models of the mission space to provide a basis for the development of consistent and authoritative simulation representations. DMSO establishes data standards to support common representations of data across models, simulations, and commandand-control systems. DMSO also provides an infrastructure to meet the requirements of the developer and end users. Part of that infrastructure includes the MSRR, the mission of which is to facilitate sharing and reuse of information by providing a service whereby resources of interest to the DoD modeling and simulation community can be registered by their owners and discovered by other potential users. 51

APPLICATIONS FOR WEB-TO-HOST INTEGRATION MSRR provides a convenient way for DoD users to search networks for resources needed in modeling and simulation projects. The MSRR system consists of a collection of modeling and simulation resources. MSRR resources include models, simulations, object models, conceptual models of the mission space, algorithms, instance databases, data sets, data standardization and administration products, documents, tools, and utilities. MSRR users can access collections of resources utilizing a distributed system of resource servers interconnected through the Web. The MSRR system software provides for registration of resources and users, description and quality information of resources, and specialized search capabilities. The MSRR modeling and simulation resources also include information on and links to DMSO-supported projects and a DMSO document library containing various documents, briefs, and presentations relating to DMSO. The MSRR is a DoD computer system that was designed specifically for use by DoD members and contractors, although others may be provided access by DMSO MSRR program management on a case-by-case basis. MSRR users are divided into two categories: registered users and public users. A public user can use all areas of the MSRR except for the few areas that require a registered user’s ID and password. Whereas all users may access resources, registered users can register resources on the MSRR. Registered users can be included on an access list managed by the resource provider, whereas public users cannot be included on the list. Knowledge of and access to many modeling and simulation resources is limited given the plethora of information in the DoD community. MSRR collects at one Web site (including its links) the metadata about these diverse information resources. The resource may be in any form that can be distributed to other users. For example, it can be on a Web server or in the form of a hard copy. It can be in electronic form available for e-mailing or on a diskette that can be distributed through the U.S. mail. An optional item in the MSRR registration process is the Web site URL. This can refer to an Internet URL for direct access to the resource, a file transfer protocol (FTP) reference for download from a FTP site, or an e-mail address of resource point of contact. An MSRR help desk is maintained to assist users who have questions that cannot be answered solely by the modeling and simulation resources that they find while using the MSRR. The help desk can assist DoD members and DoD contractors with locating applicable information via the MSRR. A feedback mechanism is provided for users to submit their comments about the successes and failures of MSRR. The DMSO Web-based metadata repositories for modeling and simulation include the following Web sites: 52

Web-to-Information-Base Access Solutions • http://msis.dmso.mil/ • http://www.msrr.dmso.mil/ Navy Modeling and Simulation Catalog The Navy Modeling and Simulation Catalog, which is administered by the Navy Modeling and Simulation Management Office (NAVMSMO), is a part of MSRR that allows users to discover, access, and obtain modeling and simulation resources that support military assessments, training, and acquisition. It was established to provide leadership and guidance for the Navy’s modeling policy, strategy, investment, and practices; to oversee maintenance of a model repository; to provide technical assistance to model users and developers; to review resource expenditures on new model development; to sponsor initiatives for the community good; and to provide centralized coordination of U.S. Navy Modeling and Simulation. The browse capability of the Navy Modeling and Simulation Catalog provides a method of viewing data without having to run searches or execute complex queries against the database. In some cases, it is possible to “drill down” through the data in a systematic way. Metadata can be accessed by resource type, including data sources, modeling and simulation, references, support tools and utilities, related sites, all points of contact, and all organizations. The resources available at the NAVMSMO Web site are described at a substantial level of detail. In some cases, the resource will be available for immediate download. In other cases, users need to follow the specific instructions. Users can capture a summary of every resource registered in the Navy Modeling and Simulation Catalog in a single report listed by category. The Navy Modeling and Simulation Catalog includes information on data sources utilized in Navy modeling and simulation activities, models, simulations, and simulators found in the current Navy inventory. It also has references to publications and tools utilized in the support, development, and management of Navy modeling and simulation. DMSO and NAVMSMO both provide links to service-specific, joint, and allied organizations of interest to modeling and simulation users, such as those listed in Exhibit 5-1. CASE STUDY 3: KNOWLEDGE-BASE DEVELOPMENT AND ACCESS USING THE WEB What Is a Knowledge Base? Unfortunately, a comprehensive, exclusive, and unique definition of the term “knowledge base” that will satisfy all knowledge engineers is not available. However, a working definition that will cover many cases is as follows: 53

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Navy Modeling and Simulation Management Office (NAVMSMO)

http://navmsmo.hq.navy.mil/nmsiscat/

Air Force Communications Agency Modeling and Simulation Home Page

http://infosphere.safb.af.mil/~tnab/

Army Model and Simulation Office

http://www.amso.army.mil/

Joint Data Base Elements for Modeling and Simulation

http://208.145.129.4/

Defense Modeling, Simulation, Tactical Technology Information Analysis Center

http://dmsttiac.hq.iitri.com/

U.K. Simulation Interoperability Working Group

http://siwg.dra.hmg.gb/

Exhibit 5-1.

Modeling and simulation Web sites.

Unlike a database that stores information implicitly in tabular format, a knowledge base is a source of information that stores facts explicitly as declarative assertions, such as frames and slots, or in the form of probabilistic networks. (See, for example, Reference 2.) Implicit in the definition is the idea that a knowledge base is used as input into an inference engine in an expert system. Web sites that provide access to knowledge bases can be divided into two categories: (1) those that can be accessed by Lisp or other programming languages and that could be used as input to an inference engine without extensive knowledge representation modification, and (2) those that amount to plain textual information written in nonprogramming, spoken language, such as English or French. In some cases, the distinction between the two categories is ill-defined. For example, the test of “can the candidate knowledge base be input into an inference engine?” fails as a means to exclude what we usually think are some nonknowledge-base information sources because some software can read text, access Web sites, and extract keywords, etc., for expert systems to use. In any case, for the purpose of this chapter, all knowledge bases discussed below are assumed to be in category 1, unless otherwise noted. High-Performance Knowledge Base Technology has achieved more uniformity and interoperability with standard network protocols than it has with knowledge-base access because of the many ways in which knowledge representations can differ and also because of the multiple knowledge development methods that can be used to construct knowledge bases.3 To address these and other problems associated with the construction and usage of knowledge bases, 54

Web-to-Information-Base Access Solutions the Defense Advanced Research Projects Agency has sponsored the High Performance Knowledge Base (HPKB) program, which includes an effort to integrate via networks, knowledge base-related software, and resources.2 The HPKB program includes a project titled “High-Performance Knowledge Editing and Problem Solving over the Internet.”2 A key concept with this approach is that the application specialists should be able to use domain-specific editors over the Internet in a collaborative environment to develop knowledge bases. The Internet is a tool that potentially can be used to search for domain-independent, problem-solving components that can be linked to the domain-oriented knowledge bases.2 The project will provide retrieval methods of ontologies and knowledge bases in a database system that complies with the Open Database Connectivity standards. The work is performed at the Stanford University Section on Medical Informatics, which has demonstrated access to knowledge bases over the Internet in other projects.7 The Knowledge-Base Infrastructure The University of Texas has demonstrated knowledge-base access using the Internet with its Knowledge-Base Infrastructure project. It has developed tools to help domain experts encode knowledge in multifunctional knowledge bases. Its tools include a knowledge representation language (KM) and a system (KnEd) for viewing and editing knowledge bases built using KM. Written in Common Lisp and CLIM, these tools have been ported to all major implementations of Common Lisp and hardware platforms. Whereas knowledge-base access methods are ways to locate information, many current methods are inadequate, especially for large, structured knowledge bases. To locate information about a concept using current access methods, the user would be required to provide the address (usually a frame name) of the concept within the knowledge base, which requires a level of sophistication that most users do not have. Moreover, only the concepts that already are in the knowledge base can be located, which excludes information about many concepts (meta knowledge) that is implicit in the knowledge base but that could be made explicit with the use of an appropriate inference engine. The University of Texas has developed a solution to these problems by providing an abstraction of the knowledge base in which concepts can be located by a partial description of their contents. After locating a concept, the access methods provide an additional service: selecting coherent subsets of facts about the concept. Conventional methods either return all the facts about the concept or select a single fact. These access methods extract coherent collections of facts that describe a concept from a particular perspective. The University of Texas knowledge base developers have identified many types of viewpoints and developed 55

APPLICATIONS FOR WEB-TO-HOST INTEGRATION methods for extracting them from knowledge bases. Their evaluation indicates that viewpoints extracted by our methods are comparable in coherence to those that people construct. The University of Texas has made available the software (a Lisp implementation of KM), a users manual, and a reference manual, all of which can be downloaded from its Web site; however, no warranty is stated or implied. The author(s) do not accept responsibility to anyone for the consequences of using it or for whether or not it serves any particular purpose or works at all. The authors are P. Clark and B. Porter, who can be contacted at [email protected]. Two knowledge bases of worked examples are available on the University of Texas Web site. One is the userman.km from the KM Users Manual, and the other is refman.km from the KM Reference Manual. The URL for these knowledge bases, respectively, are: • http://www.cs.utexas.edu/users/mfkb/manuals/userman.km • http://www.cs.utexas.edu/users/mfkb/manuals/refman.km University of Indiana Knowledge Base The knowledge in this Web-based information system includes databases of Standard & Poor’s corporate financial statements and the Center for Research in Security Prices. Indiana University’s license is restricted to students, faculty, and staff. The URL is http://sckb.ucssc.indiana.edu/kb/ data/adyx.html and the point of contact is Lin-Long Shyu at [email protected]. The knowledge base consists of 5000 files, each with a question and an answer formatted in Knowledge Base Markup Language (KBML), a text markup language described using Standard General Markup Language. KBML is similar to HTML with some adaptations and special features required by the knowledge base. The system features a locally written, full-text search engine called “Mindex”; a freeware Web server, Apache; several databases, including an extensible keywords database; tools and utilities for knowledge base usage reports and text maintenance, including an editing environment written in Emacs Lisp; and Web and command-line tools for searching in various modes. The system is maintained actively by consultants who work for University Information Technology Services’ Support Center. ADM Medical Knowledge Base The ADM (Aide au Diagnostic Médical) is a system with an extensive medical knowledge base. Its two main goals are to help physicians make diagnoses and enable rapid access to medical information through telematic networks. The system can be used in many ways: diagnosis evocation, strategy 56

Web-to-Information-Base Access Solutions in asking for complementary tests, interaction between disease and drug, interaction between disease and pregnancy, and electronic encyclopedia. The knowledge base, which deals with all medical domains, contains the descriptions of 15,600 diseases, syndromes, and clinical presentations. It includes a data dictionary of 110,000 entities and a vocabulary dictionary with 45,000 terms. The database is implemented with a relational database management system. It is composed of several tables that physicians update regularly. The telematics consultation system is available on a Web server. Whereas everyone may access the demonstration version, the use of the entire system is restricted to physicians who have received a password. They can use menus and text as dialogue with the system. Question types are defined, and the encyclopedic aspect has been developed. Other functions, particularly the diagnosis evocation module, are being improved and will be consulted by students and researchers on the university network using the intranet Web server. The user interface features seminatural language using dictionaries and hierarchies defined in the database. The URL that describes the ADM Medical Knowledge Base URL is http://sunaimed.univ-rennes1.fr/plaq/proj_an/adm_an.html. It is available in English or French. The information in French is available at http://www.med.univ-rennes1.fr/adm.dir/presentation.html. Commercial Knowledge-Base Services This information about products and services is provided for user convenience and is not intended to be an advertisement or an endorsement by the U.S. government. The Help Desk Institute has provided the Web-based service of describing the expert systems and knowledge base tools and services that are available in private industry. The root URL is http://www.helpdeskinst.com/ bg/contents.html, which features links to a wide range of commercial vendors that supply knowledge base access and expert system–related services to their clients and customers, particularly in the area of online help desks. Some knowledge publishers and companies that provide knowledge bases accessible over the Internet are listed at the following URL: http://www.helpdeskinst.com/bg/sections/knowledgepubs/index.html. The 1998 Support and Services Suppliers Directory also describes companies that offer expert systems and knowledge support tools at the following URL: http://www.helpdeskinst.com/bg/sections/expertsys/index.html. For example, some of these companies that provide the above-described services are listed on the Web site of the Help Desk Institute with their URL, as listed in Exhibit 5-2. 57

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Advantage KBS Inc.

http://www.akbs.com

Emerald Intelligence Inc.

http://www.emeraldi.com

Intellisystems Inc.

http://www.intellisystems.com

KnowledgeBroker Inc.

http://www.kbi.com

The Haley Enterprise

http://www.haley.com

Magic Solutions Inc.

http://www.magicsolutions.com

Molloy Group Inc.

http://www.molloy.com

Product Knowledge Inc.

http://www.proknowledge.com

ServiceSoft Corp.

http://www.servicesoft.com

ServiceWare Inc.

http://www.serviceware.com

Software Artistry Inc.

http://www.softart.com

Utopia Technology Partners Inc.

http://www.utosoft.com

Exhibit 5-2.

Commercial knowledge-base services.

The electronic document management (EDM) application management software from Amdahl Corp., enabled by Novadigm, is an automated software management product that deploys and continuously synchronizes changes to client/server software on numerous heterogeneous, distributed desktops and servers. EDM support and knowledge-base access is limited to licensed customers with password. The EDM Amdahl URL is http://amdahl.com/aplus/support/EXedm_sup.html. The DataWorks Corp.’s education and support services provide access to an online knowledge base of documents that contain solutions to numerous questions. Online application and technical support to customers is available through SupportNet 24 hours a day, 7 days a week. The DataWork’s URL is http://www.dataworksmpls. com/support/. Some Web sites provide access to knowledge bases that are actually collections of databases or documents through a system of point-andclick queries. These fall into category 2 as described above. Technically, they are knowledge bases if they contain information stored in a declarative manner; however, the information is not necessarily stored in a format that the kind of inference engines used in expert systems can access and read. For example, Netscape provides a list of online documents that can be accessed via the Web. When Netscape describes how to browse the 58

Web-to-Information-Base Access Solutions knowledge base, it refers to an index to lists of technical articles for various Netscape software products, current and older versions. To view technical articles, the user must select a link. Whereas this can be of considerable utility to enable users to gain information about the contents the online documents, there is no evidence that the documents have been stored using a knowledge representation that a Lisp program, for example, could read as input. The URL for Netscape’s Browse the Knowledge Base is http://help.netscape.com/browse/. The Visionware Ltd.’s Support URL offers its knowledge base as an exclusive and free service for Visionware customers. It is described at the following URL: http://www.visionware.com/support.asp. It features online product support that offers search facilities to locate known problems and problem reports in the Visionware knowledge database. According to Verity Inc., a knowledge base consists of a set of predefined queries called “topics” that users can select to include as search criteria in their information agents. Information about Verity’s knowledge base is l o c a t e d a t t h e i r “ B a s i c A d m i n i s t r a t i o n A c t i v i t i e s ” We b s i t e : http://www.verity.com/tech-support/s97es/ent22u/ch013.htm. Exhibit 5-3 shows a summary of the Web sites discussed above that describe knowledge-base access using the Web. CASE STUDY 4: NETWORK-CENTRIC WARFARE Network-centric warfare, which is replacing platform-centric warfare and weapon-centric warfare, is one of the fastest-growing components in the DoD budget, not only because of the enhanced capabilities it provides to the warfighter, but also because of significant cost savings.6,12,14,17 “Platform centric” means that the purpose of a ship, submarine, airplane, or tank is defined and limited by its own sensor capabilities and ranges.3 The advantage of networkcentric warfare is that emphasis is shifted from single-platform capabilities to aggregate capabilities that provide warfighters access to an order of magnitude more information than that available on their own platform.1,14 Future platforms will be designed around information networks.1 In the Navy, network-centric warfare refers to the ability to expand horizons of each ship using computers that enable an intelligent, fast, flexible network of sensors, shooters, and command centers.14,15 This concept is becoming reality in the U.S. fleet where the new networks make command systems several orders of magnitude more effective.11,13,14 These systems are designed to assist in coordinating the widely dispersed forces operating in littorals that are expected to dominate future warfare because it increases the speed at which command decisions are made.14,16 The global military multimedia network will support voice, video, data, text, graphics, and imagery transfer between all nodes, both afloat and ashore sites.11,17 59

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Aide au Diagnostic Médical (ADM) Medical Knowledge Base

http://sunaimed.univ-rennes1.fr/plaq/ proj_an/adm_ an.html

DataWorks Corp.

http://www.dataworksmpls.com/support/.

EDM Amdahl

http://amdahl.com/aplus/support/ EXedm_sup.html

Help Desk Institute

http://www.helpdeskinst.com/bg/ contents.html

Netscape’s Browse the Knowledge Base

http://help.netscape.com/browse/

Stanford University’s Section on Medical Informatics — publications

http://smi-web.stanford.edu/pubs/

University of Indiana Compustat Knowledge-Base

http://sckb.ucssc.indiana.edu/kb/data/ adyx.html http://kb.indiana.edu/data/acte.html http://kb.indiana.edu/info/infopage.html

University of Texas Knowledge-Base Infrastructure

http://www.cs.utexas.edu/users/mfkb/ km.html

Verity Inc.

http://www.verity.com/tech-support/ s97es/ent22u/ch013.htm

Visionware Ltd.

http://www.visionware.com/support.asp

Exhibit 5-3.

Knowledge-base access web sites.

This availability of information from multiple sources, including sensors on a variety of platforms on the network, will stimulate and facilitate future advances in data-fusion software.12,13 An example of this is a key enabling network called the Joint Deployable Intelligence Support System (JDISS). Information from JDISS can be sent via international maritime satellite (INMARSAT), for example, to portable JDISS receivers on Aegis surface-combatant ships such as the nearby U.S.S. Bunker Hill (CG 52) and U.S.S. John S. McCain (DDG 56).15 Another example of network-centric warfare is the Contingency Tactical Air Planning System (CTAPS), which is a network that facilitates the construction of flight plans.15 The database, which can be updated automatically, contains the inventories of missiles, bombs, aircraft, and spares, as resources are expended. For example, when a missile is fired, users can log on to CTAPS and automatically decrement the weapons load on the ship so that all users have 60

Web-to-Information-Base Access Solutions accurate, up-to-date information.15 The network provides a significant improvement in efficiency and accuracy over paper and diskette-based flight plans.15 Other examples of technology that enable network-centric warfare are described in Reference 12. The following Web site acts as a central location for information available to the armed forces, including links to various military and U.S. government sites: http://www.military-network.com. CONCLUSION This chapter describes successful implementations of Web access to information bases, including examples in the DoD, in academia, and in industry. The Web provides access to meteorological and oceanographic data, metadata for modeling and simulation, knowledge-base development tools, and commercially available knowledge bases. It enables major paradigm shifts in the DoD such as network-centric warfare. Web technology provides solutions to growing requirements for rapid, uniform, and accurate data and knowledge access. ACKNOWLEDGMENTS The author thanks the Space and Naval Warfare Systems Command and the Defense Advanced Research Projects Agency for their support of the work described above. This chapter is the work of a U.S. government employee produced in the capacity of official duty and may not be copyrighted. It is approved for public release with an unlimited distribution. References 1. Ackerman, R. K., Bandwidth Demands Portend Revolutionary Program Taxes, Signal, 52(10), 25–29, 1998 2. Ceruti, M. G., Application of Knowledge-Base Technology for Problem Solving in Information-Systems Integration, Proc. Dep. Defense Database Colloq. ’97, pp. 215–234, Sept. 1997. 3. Ceruti, M. G., Challenges in Data Management for the United States Department of Defense (DoD) Command, Control, Communications, Computers, and Intelligence (C4I) Systems, Proceedings of the Twenty-Second Annual International IEEE Computer Software and Applications Conference, Vienna, Austria, Aug. 21, 1998. In press. 4. Evers, S., Naval forces update — U.S. Navy Seeks Fast Track to Revolution, Jane’s Defence Weekly, International Edition (JDW), 28(21) 55, 1997. 5. Frank, M., Database and the Internet, DBMS Mag., 8(13) 44–52, 1995. 6. Holland, Jr., W. J., The Race Goes to the Swiftest in Commercial, Military Frays, Signal, 52(7) 68–71, 1998. 7. Hon, L., Abernethy, N. F., Brusic, V., Chai, J., and Altman, R., MHCWeb: Converting a WWW Database into a Knowledge-Based Collaborative Environment, SMI Report No. SMI-980724, 1998. http://smi-web.stanford.edu/pubs/SMI_Abstracts/SMI-98-0724.html 8. Lawson, R., Developing Web-based Internet Applications with Reusable Business Components, Proc. Dep. Defense Database Colloq. ’96, pp. 503–520, Aug. 1996. 9. Piper, P., Defense Information Infrastructure (DII) Shared Data Environment (SHADE), Proc. Dep. Defense Database Colloq. ’96, pp. 407–418, Aug. 1996.

61

APPLICATIONS FOR WEB-TO-HOST INTEGRATION 10. Ravid, E. V., Huff, D. and Rasmussen, R., NODDS — The Next Generation: Joint METOC Viewer, Preprint volume of the 13th International Conference on IIPS for Meteorology, Oceanography, and Hydrology, pp. 203–206, Long Beach, CA, by AMS, Boston, MA, 2-7 Feb. 1997. 11. Reed, F. V., Fleet Battle Experiments Blend Naval Technology with Doctrine, Signal, 52(10) 31–34, 1998. 12. Robinson, C. A., Information Dominance Glitters among Commercial Capabilities, Signal, 52(10) 35–40, 1998. 13. Tsui, T. L. and Jurkevicks, A., A Database Management System Design for Meteorological and Oceanograpnic Applications, Mar. Techno. Soc. J., 26(2), 88–97, 1991. 14. West, L., Exploiting the Information Revolution: Network-Centric Warfare Realizes its Promise, Sea Power, 41(3), 38–40, 1998. 15. Commander Says Untold Story in Gulf is about Network Warfare, Def. Wk., 19(10), 1998. 16. Navy’s Future Depends on Secure IT and Networks, Navy News & Undersea Technology, 14(46), 1997. http://www.pasha.com/nvy/nvy.htm 17. Pentagon Arms Itself with Telecom Weapons for ‘Net-Centric’ Warfare: Nets; DoD’s First Line of Defense, Elec. Eng. Times, 975, p. 1, 1997.

62

Chapter 6

Enabling Consumer Access to Business Databases James A. Larson and Carol L. Larson

MANY BUSINESSES DEPEND ON THE AVAILABILITY OF DATABASE INFORMATION for current and potential clients. Airlines want current and potential customers to access flight departure and arrival schedules. Stockbrokers want clients to access stock quotes. Automobile dealers want prospective buyers to access descriptions of new and used cars in their inventory. Entertainment businesses want the public to access information about events and tickets. Other examples of database information needed by consumers include customer account information, package delivery information, service call/time arrival information, college class schedule information, and project schedule information. Traditionally, consumers traveled to stores, markets, or other places of business to obtain information about goods and to transact business. Sometimes, businesses approach consumers in the form of door-to-door salesmen or telemarketing calls. In today’s age of electronic communication, businesses and consumers can connect electronically to exchange information and save money. To illustrate how new technologies deliver information to customers, Exhibit 6-1 presents the Ajax Theaters movie schedule database, which will be the basis for all examples in this chapter. This chapter describes and evaluates four technologies that automate the delivery of information: interactive voice response (IVR) systems, conversational voice systems, database Web publication systems, and Internet agent-based systems. INTERACTIVE VOICE RESPONSE (IVR) SYSTEMS Interactive voice response (IVR) systems are widely used by customers to access an enterprise’s data. An IVR system presents verbal menus to consumers who, in turn, respond by pressing the buttons on their touchtone telephones. For example, a consumer dials the Ajax Theaters database telephone number and is automatically connected to the IVR system. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

63

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Exhibit 6-1.

The Ajax Theaters database.

Theater

Title

First Show

Second Show

Third Show

Fourth Show

Central Roxy Roxy Roxy Grand Grand Grand

Star Wars Star Wars Forest Gump Forest Gump Star Wars Indiana Jones Gone With the Wind

2:00 p.m. 1:00 p.m. 1:15 p.m. 1:30 p.m. 1:30 p.m. 1:45 p.m. 11:15 a.m.

4:00 p.m. 3:45 p.m. 4:15 p.m. 4:30 p.m. 4:00 p.m. 4:30 p.m. 3:30 p.m.

6:30 p.m. 6:15 p.m. 7:00 p.m. 7:15 p.m. 6:00 p.m. 6:45 p.m. 7:45 p.m.

9:30 p.m. 9:15 p.m. 9:30 p.m. 9:45 p.m. 9:00 p.m. 9:15 p.m.

A prerecorded human voice presents menus to the consumer, such as “For the Central Theater, press 1; for the Roxy Theater, press 2; for the Grand Theater, press 3.” The consumer might respond by pressing button 3 on the telephone keypad to select the Grand Theater. Exhibit 6-2 illustrates the major components of an IVR system accessing a database. The dialog manager is responsible for generating menus presented to the consumer by the IVR software. The IVR system uses either prerecorded voice files or generates a synthesized voice from text using a text-to-speech (TTS) engine. The IVR software listens for the touchtones and converts the tones to digits, which are returned to the dialog manager. The dialog manager creates an SQL request and sends it to a relational database management system (DBMS). Based on the data returned from the DBMS, the dialogue manager generates the next set of menu options for presentation to the consumer. Exhibit 6-3 shows an example of a dialogue between the IVR system and the consumer. IVR systems require users to listen to menus and remember which telephone button to press. Because users generally dislike listening to verbal menu items and their corresponding buttons, some may memorize the menus to speed the process. This problem is overcome by conversational voice systems. CONVERSATIONAL VOICE SYSTEMS Some businesses are upgrading their IVR systems to conversational voice systems, where users respond by voice rather than by pressing the buttons on their touchtone telephone. With conversational voice systems, the consumer speaks the desired option without having to listen to the long list of menu options. Exhibit 6-4 illustrates the major modules in a conversational voice system. The touchtone recognition engine in Exhibit 6-2 is replaced by an automatic speech recognition (ASR) engine. As with the IVR systems, the consumer telephones the business and is connected automatically to the conversational voice system. Either a prerecorded human voice or a synthesized voice asks the consumer questions, to which the consumer 64

Touchtone Recognition

TTS

Exhibit 6-2 IVR system.

Public Telephone System

Dialog Manager

IVR System

DBMS

Database

Enabling Consumer Access to Business Databases

65

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Exhibit 6-3.

Dialog Between IVR System and Consumer.

Dialog manager to TTS: Present the message “Welcome to the AJAX Theaters. By pressing the touchtone keys on your telephone keypad, you can hear the movie titles playing at the theater of your choice. For the movies at the Central Theater, press 1; for the movies at the Roxy Theater, press 2; for the movies at the Grand Theater, press 3.” Consumer to touchtone recognition module: Press touchtone button 3 Dialog manager to DBMS: Select Title from AjaxTheaters where Theater = “Grand” DBMS to dialog manager: Title Star Wars Indiana Jones Gone with the Wind Dialog manager to TTS: Present the message, “For the show times of Star Wars, press 1; for the show times of Indiana Jones, press 2; for the show times of Gone With the Wind, press 3.” Consumer to touchtone recognition module: Press touchtone button 3 Dialog manager to DBMS: Select FirstShow, SecondShow, ThirdShow, FourthShow from AjaxTheaters where Theater = “Grand” and Title = “Gone With the Wind” DBMS to dialog manager: Title Gone With the Wind

First Show 11:15 a.m.

Second Show 3:30 p.m.

Third Show 7.45 p.m.

Fourth Show

Dialog manager to TTS: Present the message: “The show times for Gone With the Wind at the Grand Theater are at 11:15 a.m., 3:30 p.m., and 7:45 p.m.”

responds with a word or phrase. For example, a conversational voice dialogue might proceed as described by the dialogue shown in Exhibit 6-5. With conversational voice systems, consumers can say the option name without having to listen to the entire menu. Users may even say the answer before listening to the first menu item. This enables consumers to complete the conversation faster than with IVR systems. DATABASE WEB PUBLICATION SYSTEMS Rather than use a telephone that has no display, a consumer can use a computer to access a business Web site. The consumer types in or navigates to the URL address of the business. A Web page menu appears on the 66

ASR

TTS Dialog Manager

Exhibit 6-4. Conversational voice system.

Public Telephone System

Conversational Voice System

DBMS

Database

Enabling Consumer Access to Business Databases

67

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Exhibit 6-5. Conversational Dialog. Dialog manager to the TTS: Present the message “Welcome to the AJAX Theaters. For which theater do you want information? The Central Theater, Roxy Theater, or Grand Theater?” Consumer to the ASR: “Grand” (The consumer can say “Grand” at anytime during or after the audio message from the conversational voice software.) Dialog manager to DBMS: Select Title from AjaxTheaters where Theater = “Grand” DBMS to dialog manager: Title Star Wars Indiana Jones Gone With the Wind Dialog manager to TTS: Present the message “For which movie would you like show times — Star Wars, Indiana Jones, or Gone With the Wind?” Consumer to the ASR: “Gone With the Wind” (Again, the user can say the name of the movie at anytime during or after hearing the conversational voice system message. The user is not forced to listen to the menu options to determine which touchtone button to press.) Dialog manager to DBMS: Select FirstShow, SecondShow, ThirdShow, FourthShow from AjaxTheaters where Theater = “Grand” and Title = “Gone With the Wind” DBMS to dialog manager: Title Gone With the Wind

First Show 11:15 a.m.

Second Show 3:30 p.m.

Third Show 7:45 p.m.

Fourth Show

Dialog manager to TTS: Present the message: “The show times for Gone With the Wind at the Grand Theater are at 11:15 a.m., 3:30 p.m., and 7:45 p.m.”

computer screen, from which the consumer selects an option by clicking a mouse. For example, a Web page for the Ajax Theaters is illustrated in Exhibit 6-6. If the consumer selects the Grand Theater and clicks the SUBMIT button, then the Web page illustrated in Exhibit 6-7 is displayed. Because of its visual nature, larger amounts of information can be presented to the consumer with the Web publication system faster than with the voice-oriented IVR and conversational voice systems; thus, time-consuming voice menus and verbal responses are avoided. Web pages also can 68

Enabling Consumer Access to Business Databases Welcome to the Ajax Theater Homepage. Select your desired Theater and click Submit. Central Roxy Grand Submit

Exhibit 6-6.

Home Web page for the Ajax Theaters.

present video and sound clips (sometimes called trailers) of currently playing movies. Consumers view a trailer by clicking on the movie title. Before creating a Web page, the database administrator (DBA) determines whether the page should be static or dynamic. The information on a static page does not change when data in the database is modified, while information the consumer sees on a dynamic page reflects all updates applied to the database. Static Publication of Database Information. The DBA performs SQL commands to extract data from the database to be placed on the Web page. Next, the DBA inserts the appropriate HTML codes, which specify how to present the information to the user. For example, the HTML code for the information shown in Exhibit 6-7 is shown in Exhibit 6-8. The DBA can write the HTML codes manually; however, this tedious and time-consuming task can be automated.

While it is easy to create a static Web page, the page will not reflect updates to the database. Nor does a static Web page enable the user to interact with the database. For the user to interact dynamically with the database, the DBA creates a dynamic Web page. Dynamic Publication of Database Information. Exhibit 6-9 illustrates the principal components of the dynamic publication of Web information. A common gateway interface (CGI) script is a program that runs on a database server. The CGI script performs four tasks:

• accepts a user request for data • constructs the appropriate SQL request • sends the SQL request to the relational DBMS for execution, which returns a table of resulting data • generates the appropriate HTML code to display the information and accepts the resulting table from the DBMS 69

70

1:30 P.M.

1:45 P.M.

11:15 A.M.

Star Wars

Indiana Jones

Gone With the Wind 3:30 P.M.

4:30 P.M.

4:00 P.M.

Second Show

7:45 P.M.

6:45 P.M.

6:00 P.M.

Third Show

Exhibit 6-7. Web page for the Grand Theater.

First Show

Title

Welcome to the Grand Theater. The movies currently showing are:

9:15 P.M.

9:00 P.M.

Fourth Show

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Enabling Consumer Access to Business Databases Exhibit 6-8. HTML Code for Exhibit 6-5.

Welcome to the Grand Theater.
The movies currently showing are:

<strong>Title	<strong>First Show	<strong>Second Show	<strong>Third Show	<strong>Fourth Show
Star Wars	1:30 P.M.	4:00 P.M.	6:00 P.M.	9:00 P.M.
Indiana Jones	1:45 P.M.	4:30 P.M.	6:45 P.M.	9:15 P.M.
Gone With the Wind	11:15 A.M.	3:30 P.M.	7:45 P.M.

Exhibit 6-10 displays an example of a Web-based system. Web publication systems enable consumers to interact with a remote database using a graphical Web interface. Consumers select from displayed menus rather than listening to verbal menus. Because users scan 71

72 CGI Script

Exhibit 6-9. Dynamic Web publication system.

Internet

Web Server

DBMS

Database

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Enabling Consumer Access to Business Databases Exhibit 6-10. A Web-Based System. CGI Script to Consumer: Welcome to the Ajax Theater Homepage. Select your desired Theater and click Submit. Central Roxy Grand Submit

Consumer to CGI Script: Click “Grand” radio button CGI Script to DBMS: Select Title from AjaxTheaters WHERE Theater = “Grand” DBMS to CGI Script: Theater Title Grand Star Wars Grand Indiana Jones Grand Gone With the Wind

First Show 1:30 p.m. 1:45 p.m. 11:15 a.m.

Second Show 4:00 p.m. 4:30 p.m. 3:30 p.m.

Third Show 6:00 p.m. 6:45 p.m. 7:45 p.m.

Fourth Show 9:00 p.m. 9:15 p.m.

CGI Script to Consumer Welcome to the Grand Theater. The movies currently showing are: Title

First Show

Second Show

Third Show

Fourth Show

Star Wars

1:30 P.M.

4:00 P.M.

6:00 P.M.

9:00 P.M.

Indiana Jones

1:45 P.M.

4:30 P.M.

6:45 P.M.

9:15 P.M.

Gone With the Wind

11:15 A.M.

3:30 P.M.

7:45 P.M.

displayed tables faster than listening to menus, the Web publication approach is usually faster than IVR systems. This approach may also be faster than conversational voice systems because the user only needs to recognize and select the desired option, rather than remembering and speaking the desired option. Agent-based systems combine the advantages of both the verbal-oriented IVR and conversational systems with the advantages of the visual Web-based systems. INTERNET AGENT-BASED SYSTEMS Exhibit 6-11 presents the principal modules of an agent system. An agent is a software module acting on behalf of its user by learning the consumer’s habits and desires and by performing actions compatible with those habits and desires. The agent learns by recording the consumer’s actions, analyzing 73

74

ASR

TTS

Browser

Avatar

Log

Dialog Manger

Agent Software

Exhibit 6-11. Agent system.

Internet

Web Server

DBMS

Database

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Enabling Consumer Access to Business Databases those actions in a log, and deriving heuristics for performing future actions. For example, an agent records all accesses by the consumer, determines that the user frequently requests information about action movies, and generates a heuristic for accessing information about action movies. Many software agents are written using Java, Perl, or some other machine-independent programming language. This enables the software agent to execute on a variety of computers. The software agent could reside within the Web server or within the consumer’s PC. Because some consumers are concerned about the privacy of their Web interactions, the agent and its log are placed in the consumer’s PC to guarantee privacy. In addition to logging and analyzing the functions, the agent also manages the dialogue between the user and the database management system. An agent-based system integrates the voice dialogues of conversational interfaces using a text-to-speech (TTS) engine and an automatic speech recognition (ASR) engine with the visual data displayed as Web pages. The agent itself can be displayed on the consumer’s monitor as an animated icon called an avatar, which acts like a master of ceremonies at a performance or a news anchor on a broadcast news program. The agent verbalizes the important aspects of each item displayed on the consumer’s monitor. However, unlike a news anchor, the agent asks the consumer if the consumer wants additional information. The agent assists the user in browsing for the requested information and may suggest other information as well. For example, if the consumer recently watched several action films, the agent might suggest additional action films for consideration by the consumer. Exhibit 6-12 displays a sample agent-based system dialogue. Like Web-based systems, agent-based systems present visual menus to consumers, who can then quickly recognize and select desired options. In addition, Web-based systems use heuristics to simplify the process for the user by suggesting likely choices to the user. EVALUATION AND COMPARISON Exhibit 6-13 summarizes the strengths and weaknesses of the four technologies enabling consumers to access a database. Potential Audience. The potential audience for IVR and conversational systems is high because over 95 percent of U.S. households have access to touchtone telephones. The prospective audience for Web access is medium because only about 20 percent of U.S. households have personal computers with Internet connections. The possible audience for a Web agent is lower still because only a portion of the households with Internet connections have sound capability on their computers. 75

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Exhibit 6-12.

Agent-Based System Dialogue.

Agent to the consumer’s Web browser: Welcome to the Ajax Theater Homepage. Select your desired Theater and click Submit. Central Roxy Grand Submit

Agent to TTS: Present the message “Welcome to the AJAX Theaters. You usually ask for movies playing at the Grand Theater. Should I display this information now?” Consumer to ASR: “Yes.” Agent to DBMS: Select Title from AjaxTheaters where Theater = “Grand” DBMS to dialog manager: Title Star Wars Indiana Jones Gone With the Wind Dialog manager to the consumer’s Web browser: Display the Web page showing the movies playing at the Grand Theater. Dialog manager to TTS: Present the message “Here are the movies playing at the Grand Theater. You usually prefer action movies. Do you wish to see the show times for Star Wars and Indiana Jones?” Consumer to agent: “Yes.” Dialog manager to DBMS: Select Title, Select FirstShow, SecondShow, ThirdShow, FourthShow from AjaxTheaters where Theater = “Grand” and (Title = “Star Wars” or Title = “Indiana Jones”) DBMS to dialog manager: Title First Show Star Wars 1:30 p.m. Indiana Jones 1:45 p.m.

76

Second Show 4:00 p.m. 4:30 p.m.

Third Show 6:00 p.m. 6:45 p.m.

Fourth Show 9:00 p.m. 9:15 p.m.

Enabling Consumer Access to Business Databases Exhibit 6-12.

Agent-Based System Dialogue (continued)

Dialog manager to consumer’s Web browser: Welcome to the Grand Theater. The movies currently showing are:

Title

First Show

Second Show

Third Show

Fourth Show

Star Wars

1:30 P.M.

4:00 P.M.

6:00 P.M.

9:00 P.M.

Indiana Jones

1:45 P.M.

4:30 P.M.

6:45 P.M.

9:15 P.M.

Gone With the Wind

11:15 A.M.

3:30 P.M.

7:45 P.M.

Dialog manager to TTS: Present the message “Here are the show times for Star Wars and Indiana Jones.”

Business Expense to Create. Creating IVR and conversational systems involves the purchase of special hardware to integrate the telephone with the data server. IVR and verbal dialogues also must be designed and tested carefully. Conversational dialogues are more difficult to create because they must constrain the consumer’s responses to a small number of words or phrases that can be understood by an automatic speech recognition engine. On the other hand, creating dynamic Web pages containing database information is straightforward when using Web page creation tools. Unfortunately, tools for creating Web agents that are both visual and verbal are not yet widely available. Consumer Acceptance. Consumers dislike IVR systems because they frequently require the consumer to listen to long verbal menus and remember which key on the telephone keypad to press. Instead, users generally prefer conversational systems because questions are answered quickly, without having to listen to the long verbal menus. Customers will prefer the visual menu options of the Web and Web-agent interfaces because they will be able to select options quickly. Most likely, the Web agent will become the most popular because consumers will be able to respond either by clicking or by speaking, whichever is more convenient. Exhibit 6-13.

Comparison of the Four Approaches.

IVR

Conversational

Web Access

Web Agent

Type of access

Hear and click

Hear and speak

See and click

Potential audience Business expense to create/maintain Consumer acceptance

High Low-medium

High Medium

Medium Low

Hear/see/click or speak Low High

Low

Medium

Medium

High

77

APPLICATIONS FOR WEB-TO-HOST INTEGRATION RECOMMENDATIONS IVR and conversational speech systems provide the greatest potential for consumers to access an enterprise’s database. If already using an IVR system, an enterprise should consider upgrading to a conversational speech system. If an IVR system is not used, then a conversational speech system should definitely be considered. Although it is more difficult to implement, the acceptance of a conversational speech system among consumers is expected to be greater than that of the IVR system. Database Web publication systems provide easy-to-browse facilities to an enterprise’s database for customers with a Web-enabled computer. While Web agents promise improved consumer satisfaction, this has not yet been demonstrated. The success of visual-verbal agents on the Internet should be monitored. Consider converting the enterprise’s Web pages to visual-verbal agents when the technology proves to be consistently useful. Until the U.S. population has greater access to the World Wide Web, both conversational speech systems and Web pages are recommended. This enables most consumers to speak and hear information from a database via telephone, while consumers connected to the Internet can see and select information from the database. RECOMMENDED READINGS The following book describes technologies and management of call centers, including integration with IVR. Dawson, K. The Call Center Handbook: The Complete Guide to Starting, Running, and Improving Your Call Center, San Francisco, CA: Miller Freeman Books, 1998. The following books explain how to write CGI scripts using two popular scripting languages — PERL and Java. Brenner, S. and Aoki, E. Introduction to CGI PERL: Getting Started with Web Scripts, Foster City, CA: IDG Books World-Wide, 1996. Rahmel, D. Server Scripts with Visual Javascript (Hands-On Web Development), New York: McGraw-Hill, 1997. The following book gives an overview of Microsoft’s Web publishing tools. Chandak, R. Web Programming with Microsoft Tools 6 in 1. Indianapolis: Que Education & Training, 1997. The enterprise’s DBMS vendor should be consulted for Web-publishing tools compatible with the enterprise’s DBMS.

RECOMMENDED WEB SITES The following Web sites contain the telephone numbers with several demonstrations of conversational speech interfaces. Applied Language Technology (ALTech), http://www.altech.com. Nuance Communications, http://www.nuance.com. This Web site contains demonstrations of 3-D graphical avatars that could be used as visualized agents: Fluent Speech Technologies, http://www.fluent-speech.com.

78

Chapter 7

Web-Enabled Data Warehouses Mary Ayala-Bush John Jordan Walter Kuketz

DELIVERING DATA WAREHOUSE ACCESS VIA WEB BROWSERS HAS A VARIETY OF BENEFITS. Inside a corporate intranet, Web-enabled data warehouses can increase ease of use, decrease some aspects of training time, and potentially cut costs by reducing the number of proprietary clients. Upgrades can also be accelerated given a standard client, and data warehouses can more easily integrate with other applications across a common platform. Extended to corporate trading partners via a so-called extranet (a secure extension of an intranet outside a firewall), the information contained within a data warehouse may be of sufficient value to become a revenue source. While such internal and external benefits may be appealing, they do not come without complicating issues. In these traditional implementations, data warehouses have been used by a small population of either highly trained or high-ranking employees for decision support. With such a small audience having the warehouse application on their desktop, access control was straightforward: either the end user could access a given table or not. Once the warehouse begins to be accessed by more people — possibly including some outside of the company — access may need to be restricted based on content. Security concerns also change as the user population increases, with encryption over the public Internet being one likely requirement. Because Web-based access to a data warehouse means expanding the community of people who will access the data, the types of queries will most likely be more varied. Better business intelligence may thereby be derived, but once again not without complications. In addition to security, performance (and therefore cost) issues become immediately relevant, dictating reconsideration of everything from replication patterns to log-in requirements. This chapter explores how Web-enabled 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

79

APPLICATIONS FOR WEB-TO-HOST INTEGRATION data warehouses change the strategy, architecture, infrastructure, and implementation of traditional versions of these applications STRATEGY Business Relationships The strategy for a Web-based data warehouse should answer at least two questions: • Who is being granted access? • Why are they being granted access via the Web model? Answering these two questions will supply important information for the cost justification of broader access. Possible justifications might include getting better service from vendors, facilitating better relationships with customers, shortening time of products in the supply chain, and receiving revenues from an internal application. The implications of broader access include having to design an architecture flexible enough to allow for new audiences with needs and requirements that may not be well identified. In addition, going into the information business can distract a company from its core focus: how are pricing levels determined? How does revenue derived from a potentially unexpected external source change payback and ROI models? What are the service level agreements and how are they determined? Who becomes the customer service liaison, especially if the IS organization is already running at full capacity for internal constituencies? Access Control and Security Security is a primary consideration when contemplating Web access to sensitive corporate information. Authentication can be required at three separate stages, allowing administrators to fine-tune who sees what when, while encryption (typically through the use of the Secure Sockets Layer, or SSL) protects both queries and responses from being compromised in transit. Initially, the Web server can require either name and password log-in or the presence of a certificate issued by the data warehouse administrator. This grants access to the site and triggers the SSL encryption if it is implemented. Once inside the data warehouse, the user might also be required to authenticate himself at the query server, which allows access to the appropriate databases. This might be a dedicated data mart for a vendor, for example, that precludes vendor A from seeing anything pertaining to vendor B, whose information is held in a logically (and possibly physically) separate data mart. Finally, authentication may be required by the database to limit access within a given body of data: a clerk at vendor A can see only a selected portion of the A data mart, while A’s president can see that company’s entire data mart. 80

Web-Enabled Data Warehouses The logistics of security can be extensive. Maintaining certificates requires dedicated resources, while planning for and executing multi-tiered log-ins is a nontrivial task. At the same time, limiting access can imply limiting the value of the data warehouse, so security must be designed to be flexible and as friendly to legitimate users as possible. New Components Broader access to a data warehouse introduces a number of new elements into the traditional application model. What happens to the query engine vendor’s pricing model as its proprietary desktop clients are no longer required? Where are the skill sets and hardware to implement Web servers and connect them to the query engine? How much will data be transformed (and by whom) if it is moved out of a central data warehouse into data marts for security, performance, or other reasons? ARCHITECTURE If strategy is concerned with goals and objectives, architecture is the unifying conceptual design or structure. It defines a system’s component parts and relationships. Good architectures ensure that the component hardware and software pieces will fit together into an integrated whole. A Web-enabled data warehouse introduces additional components within a system architecture, which must be expanded to include: • the Web server component • the components that connect the Web server to the query engine • the component that formats the results such that they are viewable by a Web browser The system architecture may also need a component for integrating data marts. Even given these elements, the architecture must be flexible enough to change rapidly, given both the pace of innovation in the Internet arena and the evolving place of data warehouses in contemporary business. The warehouse components may change due to increasing numbers of people using it, changing aggregations based on security or performance requirements, new access paths required by technological or organizational evolution, etc. New design considerations are introduced by each of the above components. Web servers introduce new complications, particularly in regard to scalability issues. Secure transactions over a dial-up connection can be painfully slow, but detuning the security at either the firewall or the Web server can expose the corporate network to risk. Middleware between the Web server and the query server can dramatically affect performance, 81

APPLICATIONS FOR WEB-TO-HOST INTEGRATION particularly if common gateway interface (CGI) scripts are used in place of APIs. Database publishing to HTML is reasonably well-advanced, but even here some of the newest tools introduce Java programming into the mix, which may cause implementation problems unless the skills are readily available. Java also presents the architect with new ways to partition the presentation layer and the application logic, with implications (for the network and desktop machines in particular) that are only beginning to be experienced in enterprise computing. The system architecture must support competing enterprises accessing the data sources. One challenge is to support competing vendors where access control is data dependent. Both vendors can query the same tables; for example, by product, by region, by week. If a given retail outlet sells both vendors’ products, and people from the sales outlet are allowed to query the data warehouse, they will need access to both vendors’ history. A good system architecture must include the facility for access control across the entire Web site, from the Web server through to the database. If a mobile sales force will be given access while they are on the road, the architecture must have a component to address the types of connections that will be used, whether they are 800 dial-up services, local Internet service providers (ISPs), or national ISPs such as CompuServe or AOL. INFRASTRUCTURE The infrastructure required to support the Web-enabled data warehouse expands to include the Web site hardware and software, the hardware and software required to interface the Web server to the query server, and the software that allows the query server to supply results in HTML. The corporate network may have to be altered to accommodate the additional traffic of the new data warehouse users. This expansion increases the potential complexity of the system, introduces new performance issues, and adds to the costs that must be justified. The Web-enabled warehouse’s supporting infrastructure also introduces new system administration skills. Because the warehouse’s DBA should not be responsible for the care and feeding of the Web site, a new role is required — the Web site administrator, often called the webmaster. This term can mean different things to different people, so clarity is needed as the position is defined. Depending on the context, corporate webmasters may or may not be responsible for the following: • • • • 82

designing the site’s content architecture writing and editing the material designing the site’s look-and-feel monitoring traffic

Web-Enabled Data Warehouses • configuring and monitoring security • writing scripts from the Web server to back-end application or database servers • project management • extracting content from functional departments The amount of work that may have to be done to prepare for Internet or intranet implementation will vary greatly from company to company. For example, if the warehouse is going to be accessible from the public Internet, then a firewall must be put in place. Knowing the current state of Webbased application development is essential: if organizational factors, skills, and infrastructure are not in place and aligned, the data warehouse team may either get pulled from its core technology base into competition for scarce resources or be forced to develop skills largely different from those traditionally associated with database expertise. Web Site Web site components include the computer to run the Web server on and the Web server software, which may include not only the Web listener but also a document manager for the reports generated from the warehouse. One of the Web protocols, called the Common Gateway Interface, allows the Web browser to access objects and data that are not on the Web server, thereby allowing the Web server to access the data warehouse. The interface used does not access the warehouse directly but will access the query engine to formulate the queries; the query engine will still access the warehouse. The CGI has been identified as a bottleneck in many Web site implementations. Because the CGI program must incur the overhead of starting up and stopping with every request to it, in high-volume systems this overhead will become pronounced and result in noticeably slow response times. API access tends to be faster, but it depends on the availability of such interfaces from or in support of different vendors. Application Query Engine The infrastructure must support the application query engine, which may run on the same computer as the data warehouse or on a separate computer that is networked to the data warehouse computer. This component must be able to translate the query results into HTML for the server to supply to the browser. Some of the query engines will present the results in graphic form as well as tabular form. Traditional warehouses have supported relatively small user communities, so existing query engines will have to be monitored to see how their performance changes when the number of users doubles, triples, or increases by even larger multiplers. In addition, the type and complexity of the queries will also have performance implications that must be addressed based on experience. 83

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Data Warehouse The infrastructure for the data warehouse is not altered simply because Web browsers are being used; instead, the expanded number of users and new types of queries this may need to be executed will likely force changes to be made. When a data mart architecture is introduced for performance or security reasons, there may be a need to change where the mart will be located: on the same machine as the warehouse, or on a separate machine. The infrastructure will have to support both the method of replication originally specified and new patterns of replication based on DASD cost considerations, performance factors, or security precautions. Security Web Server Access. Access to the Web server can be controlled by: (1) requiring the user to log into the Web site by supplying a user name and password, (2) installing client certificates into the browsers of the clients to whom access is granted, or (3) specifying only the IP addresses that are allowed to access the Web site. The client certificate requires less interaction on the user’s part because they will not have to supply a user name and password to access the system. The client’s certificate is sent to the Web server, which will validate the certificate and grant the user access to the system. (Part of the process of enabling a secure Web site is to install a server certificate. This must be requested from a third party, called a certificate authority, which allows one to transmit certificates authenticating that someone is who they say they are.) A less secure strategy is to configure the Web server to allow connection from a selected number of computers, with all others being categorically denied access. This scheme will allow anyone from an authorized computer — as opposed to authorized persons — to access the Web site. Because this method is based on IP address, DHCP systems can present difficulties in specifying particular machines as opposed to machines in a particular subnet. Communication Transport Security. Both the query and especially the information that is sent back to the browser can be of a sensitive nature. To prevent others along the route back to the browser from viewing it, the data must be encrypted, particularly if it leaves the firewall. Encryption is turned on when the Web server is configured, typically via the Secure Socket Layer (SSL) protocol. Query Server Application. To access the query server, the user may be asked to supply a user name and password. The information supplied by the certificate could be carried forward, but not without some custom code. There are various approaches to use to for developing the user names and passwords: one can create a unique user name for each of the third parties that will access the system (allowing the log-in to be 84

Web-Enabled Data Warehouses performed on any machine), or create a unique user name for each person who will access the warehouse. Each approach has implications for system administration. Database Access. Database access can be controlled by limiting the tables users and user groups can access. A difficulty arises when there are two competing users who must access a subset of the data within the same table. This security difficulty can be solved by introducing data marts for those users, where each data mart will contain only the information that particular user is entitled to see. Data marts introduce an entirely new set of administrative and procedural issues, in particular around the replication scheme to move the data from the warehouse into the data mart. Is data scrubbed, summarized, or otherwise altered in this move, or is replication exact and straightforward? Each approach has advantages and drawbacks.

IMPLEMENTATION The scope of implementing a Web-enabled data warehouse increases because of the additional users and the increased number of system components. The IS organization must be prepared to confront the implications of both the additional hardware and software and of potentially new kinds of users, some of whom may not even work for the company that owns the data in the warehouse. Intranet Training will need to cover the mechanics of how to use the query tool, provide the user with an awareness of the levels (and system implications) of different queries, and show how the results set will expand or contract based on what is being asked. The user community for the intranet will be some subset of the employees of the corporation. The logistics involved with training the users will be largely under the company’s control; even with broader access, data warehouses are typically decision-support systems and not within the operational purview of most employees. Implementing security for the intranet site involves sensitizing users to the basics of information security, issuing and tracking authentication information (whether through certificates, passwords, or a combination of the two), and configuring servers and firewalls to balance performance and security. One part of the process for enabling a secure Web server is to request a server certificate from a certificate authority. Administratively, a corporation must understand the components — for example, proof of the legal right to use the corporate name — required to satisfy the inquiries from certificate authority and put in place the procedures for yearly certificate renewal. 85

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Monitoring a Web-based data warehouse is a high priority because of the number of variables that will need tuning. In addition, broader access will change both the volume and the character of the query base in unpredictable ways. Intra/Extranet In addition to the training required for internal users, training is extended to the third parties that will access the warehouse. Coordination of training among the third parties will likely prove to be more difficult: competing third parties will not want to be trained at the same time, and paying customers will have different expectations as compared with captive internal users. In addition, the look and feel within the application may need more thorough user interface testing if it is a public, purchased service. Security gets more complex in extranet implementations simply because of the public nature of the Internet. It is important to keep in mind the human and cultural factors that affect information security and not only focus on the technologies of firewalls, certificates, and the like. Different organizations embody different attitudes, and these differences can cause significant misunderstandings when sensitive information (and possibly significant expenditures) are involved. Monitoring and tuning are largely the same as in an intranet implementation, depending on the profiles of remote users, trading partner access patterns, and the type and volume of queries. In addition, a serious extranet implementation may introduce the need for a help desk. It must be prepared to handle calls for support from the third parties, and combine customer service readiness with strict screening to keep the focus on questions related to the data warehouse. It is not impossible to imagine a scenario in which the third-party employees will call for help on topics other than the warehouse. CONCLUSION Because Web browsers have the ability to save whatever appears in the browser, in Web-enabled data warehouses, information that appears in the browser can be saved to the desktop. Protecting information from transmission into the wrong hands involves a balancing act between allowing for flexibility of queries and restricting the information that can potentially move outside corporate control. Legal agreements regarding the use of information may need to be put in place, for example, which tend not to be a specialty of the IS organization. Pricing the information can be another tricky area, along with managing expectations on the part of both internal and third-party users. 86

Web-Enabled Data Warehouses By their very nature, however, data warehouses have always been more subject to unintended consequences than their operational siblings. With changing ideas about the place and power of information, new organizational shapes and strategies, and tougher customers demanding more while paying less, the data warehouse’s potential for business benefit can be increased by extending its reach while making it easier to use. The consequences of more people using data warehouses for new kinds of queries, while sometimes taxing for IS professionals, may well be breakthroughs in business performance. As with any other emerging technology, the results will bear watching.

87

Chapter 8

Real-Life Case Studies of Web-toHost Integration Anura Gurugé

COMPARED

TO OTHER DATA CENTER TECHNOLOGIES ,

WEB-TO-HOST

integration solutions, which only came into being in mid-1996 with the introduction of the first 3270-to-HTML conversion product, are a very recent entrant into the rather conservative mainframe and AS/400 arena. Nonetheless, the appeal and applicability, not to mention the return on investment (ROI) of these TCP/IP-centric solutions, are so cogent and obvious that by mid-1999, nearly a thousand corporations around the world had successfully adopted Web-to-host integration — this despite the major distraction of Y2K concerns. Many of the early adopters of Web-to-host integration were well-known blue-chip companies such as General Motors, FedEx, American Airlines, Trans World Airlines (TWA), Bank of America, Charles Schwab, Nestlé, and Del Monte Foods. Charles Schwab, the world’s largest discount brokerage, now does over 60 percent of its trades online, across the Internet, using Web-to-host technology coupled to six IBM mainframes. The adoption rate of Web-to-host integration will increase even further when data center professionals, around the globe, recover from their Y2K travails. This chapter sets out to help future adopters of Web-to-host integration technology by describing in detail six salutary case studies — each using a different type of Web-to-host solution. Each of these case studies clearly demonstrates the viability, potency, and stability of today’s Web-to-host integration technology. The Lafayette Life and The Farmers Mutual Protective Association of Texas case studies, both from the insurance sector, dramatically highlight the incontrovertible cost benefits of using the Internet as the means of providing remote access to data centers. Lafayette Life reduced its remote access costs by over 90 percent by moving from a public Frame Relay network-based access scheme to a Web-to-host solution that enabled them to securely and reliably realize the same host access — but this time 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

89

APPLICATIONS FOR WEB-TO-HOST INTEGRATION Exhibit 8-1. Key characteristics of six case studies

Customer

Industry Sector

Web-to-Host Technology

Lafayette Life Insurance

Insurance

3270-to-HTML

The Farmers Protective Assoc. of Texas Sabre (U.K.)

Insurance

Java applet based tn5250 emulation 3270-to-HTML

Charleston County Court Navarre Corp.

Local government Entertainment

The Chickering Group

Insurance

Transport

3270-to-HTML Java appletbased tn3270(E) emulation and 3270-toHTML Java appletbased tn5250 emulation

Key Payoff Reduce remote access costs Enable remote access

Solution Provided By

Rejuvenated User Interface

Sterling Software

Yes

ResQNet.com

Yes

Minimize Novell installation and maintenance costs with thin client Public access Intelligent to mainframe Environments Business-toICOM business Informatics E-commerce over the Internet Zero lead-time Farabi for Technology implementin g host access

Yes

Yes Limited

No

across the public Internet. Although a very successful, 98-year-old insurance company with 300 sales agents, The Farmers Mutual Protective Association of Texas could only justify online, remote access for these 300 agents when it discovered a Web-to-host integration solution that supported unrestricted AS/400 access across the Internet. The remaining four case studies demonstrate other advantages of Web-to-host integration such as the cost savings of thin-client access, business-to-business E-commerce over the Internet, and the zero-lead-time attribute of using the Internet as a means for host access. The key characteristics of these six case studies can be summarized as shown in Exhibit 8-1. LAFAYETTE LIFE INSURANCE Lafayette Life Insurance (Lafayette, Indiana), founded in 1905, is a $9.5 billion super-heavyweight operating in 48 states plus Washington, D.C. In addition to traditional life insurance products, it offers a broad range of insurance and financial planning services. Lafayette’s growing business is 90

Real-Life Case Studies of Web-to-Host Integration sustained by a large corporate staff in Indiana, augmented by approximately 1000 field agents across the country. All of the field agents plus the corporate staff have realtime, online access to policy information, customer records, beneficiary status, marketing material, as well as all necessary forms and documentation. Highquality, responsive customer service, instantaneous quotes on policies, and an “on-the-spot” information provision are imperative to success in today’s competitive insurance and financial planning market. Lafayette excels in, and is totally committed to, ensuring that its agents have access, around the clock, to all of the information they need to help them be successful. To this end, Lafayette has an in-house developed Policy Information System — written in S/370 Assembler to maximize performance and efficiency. This system, known as the New On Line Administration System (NOLAS), provides online access to all of the requisite information, forms, and documentation. Lafayette is a VM/SP shop that currently has a twoprocessor unit, IBM 9672-R24, S/390 Parallel Enterprise Server. Field agents initially gained access to NOLAS via IBM’s Advantis Global Network. But this was becoming an expensive proposition that cost Lafayette $6.50 per hour for every agent logged on. Agents who were not served by a local access number for Advantis were forced to use a 1-800 number that cost Lafayette $6.00 per hour, per user. Proactively containing costs is vitally important in today’s competitive insurance market, with any measures that reduce the cost per policy typically getting reflected, positively, in the company bottom line. In order to dramatically slash these access costs, Lafayette decided to pursue an Internet-based access solution. Lafayette chose Sterling’s VM:Webgateway 3270-to-HTML conversion offering as the means to provide browser-based access, replete with user interface rejuvenation, to NOLAS. Exhibit 8-2 shows the architecture of this VM:Webgateway host access solution. VM:Webgateway is a highly scalable and secure, VM-based 3270-to-HTML conversion product. Contrary to its name, VM:Webgateway is not a VM-only solution. Instead, think of it as a very high-capacity 3270-to-HTML offering that happens to run on a VM server as opposed to an NT or Novell server. It can be profitably used to Web-enable any SNA/3270 application running on a MVS, OS/390, VM, VSE, or TPF system. All that is required are standard SNA connections between the VM system running VM:Webgateway and the other mainframes containing the SNA/3270 applications. VM:Webgateway includes a built-in, full-function Web server that supports SSL-based security as well as Java and ActiveX applets. On a medium-size mainframe, VM:Webgateway can support a couple of thousand concurrent sessions, replete with screen rejuvenation, without any problem. A scalability number that is in the thousands, as opposed to 91

Exhibit 8-2.

Mainframe-centric 3270-to-HTML conversion, based on Sterling Software’s VM:Webgateway, as used by Lafayette Life Insurance.

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

92

Real-Life Case Studies of Web-to-Host Integration tens of thousands, might appear to be incongruous vis-à-vis SNA access. However, in the case of 3270-to-HTML, one has to factor in all the processing associated with the bi-directional conversions involved, as well as the overhead of performing the rejuvenation-specific functions — such as that of executing the scripts that do the actual user interface customization. Consequently, many of the 3270-to-HTML offerings that run on NT-based PCs do not typically advertise concurrent session counts that are in excess of a thousand. Hence, the mainframe-based VM:Webgateway approach is definitely, and not unexpectedly, more scalable than most other 3270-toHTML solutions. With VM:Webgateway, the 3270-to-HTML conversion is done via individually created Common Gateway Interface (CGI) scripts that are written using IBM’s REXX (i.e., Restructured Extended Executor) job scripting language. The CGI scripts gain access to the mainframe applications that are to be Web-enabled by logging on to them using standard, mainframe userid/password logon conventions. Sterling does provide an automatic tracing facility that records — in terms of a CGI script — the navigation process employed by a user to access and interact with 3270 screens. A skeleton CGI script obtained via this tracing scheme can then be fleshed-out to provide the complete rejuvenated user interface. In addition, Sterling also provides CGI scripts that will automatically apply a set of default transformations, such as background and buttons, to any “green-on-black” 3270 screen. To ensure session integrity and security, VM:Webgateway uses “hidden” HTML FORM fields to store session ID numbers. Given that it is a long-standing, dedicated VM shop, Lafayette did not hesitate in opting for a VM-based mainframe solution for its Web server, as well as its Web-to-SNA gateway. Implementing NT or UNIX servers in order to realize Web enablement was viewed as unnecessary distraction and overhead — especially since Sterling could provide them with a highly integrated, VM-resident solution. The conversion to Internet-based access was expedited by Lafayette’s use of VM Assist — Sterling’s professional services partnership program. Web enablement has been a huge success, and Lafayette now openly and readily endorses the advantages of Internet-based mainframe access at every opportunity it gets. The Internet-based remote access slashed Lafayette’s remote access costs by nearly 94 percent, which has resulted in millions of dollars in cost savings each year. THE FARMERS MUTUAL PROTECTIVE ASSOCIATION OF TEXAS The Farmers Mutual Protective Association of Texas (RVOS), based in Temple, TX, is a successful mutual insurance company that provides farmers in Texas with property coverage protection against fire, theft, 93

APPLICATIONS FOR WEB-TO-HOST INTEGRATION vandalism, etc. RVOS’ forte is handling farm property insurance needs that the big, national companies are unwilling or unable to handle. RVOS was established in 1901 by a group of nine people of Czech heritage, in Bell County, Texas, for the purpose of mutual assistance to each other in the event of loss by fire, lightning, and windstorms. The acronym RVOS refers to the company’s name in Czech. RVOS has grown steadily over the years and now has 300 sales representatives spread over all of Texas. This case study is all about providing these 300 sales representatives with online AS/400 access across the Internet using tn5250 emulation, with built- in user interface rejuvenation, via a Java applet provided by ResQNet.com. Until March 1999, RVOS’ 300 sales representatives did not have any type of direct online access to the policy, claim, and financial applications that were being run on an AS/400 Model 510. Policy and claim information, prior to that, was sent to the sales representatives via mail and fax. In addition, the sales representatives would call, by telephone, the corporate headquarters in Temple when they needed online information. As with so many companies, RVOS realized a couple of years ago that the Internet was the optimum, most expeditious, and highly cost-effective way to provide its 300 (and growing) sales representatives with direct online access. In September of 1998, Lewis Wolfe, RVOS’ Computer Services Manager, saw ResQNet technology at an IBM E-business show in Las Vegas. Wolfe was impressed and initially thought that ResQNet was indeed IBM-developed technology since it was being demonstrated at an IBM booth. (ResQNet provides IBM and others with user interface rejuvenation technology. The Screen Customizer capability of IBM’s Host On-Demand Java applet is based on ResQNet technology.) After the show, Wolfe visited the ResQNet Web site (www.resqnet.com) and downloaded an evaluation copy. RVOS’ decision to go with ResQNet was based on the following two important criteria: 1. Ease of installation, implementation, and maintenance. RVOS, which has a small MIS department, wanted a solution that was easy to deploy and did not require too much maintenance. ResQNet sent a service engineer to RVOS in March 1999 and the entire project, including the design of some 20 customized screens, was successfully realized in three days. 2. AutoGUI capability. ResQNet automatically detects programmed functions key assignment strings, such as PF3 for exit, and automatically converts these strings to action buttons. ResQNet also recognizes numbered menus and automatically converts them into button-driven menus. Given that RVOS had many menu-type screens, this was of particular interest and value. Given that this AS/400 access scheme was being implemented explicitly for its dispersed sales force, RVOS wanted to deliver a welcoming, user-friendly interface that would not 94

Real-Life Case Studies of Web-to-Host Integration intimidate, frustrate, or hamper the sales representatives. RVOS also wanted to minimize, if not eliminate, help desk calls from users confused about how to “drive” the system. The ResQNet user interface rejuvenation technology compellingly addressed all of these requirements. The architecture of RVOS’ ResQNet solution is shown in Exhibit 8-3. It is a classic two-tier, client-to-host architecture. Printing, which is not a major issue, is restricted to screen prints. ResQNet uses just one applet for both the “tn” host connectivity and user interface rejuvenation. This applet is typically around 500 Kbytes — although it is possible to configure even smaller applets. In general, RVOS uses ResQNet’s caching feature, where the applet is cached in the browser’s cache after the initial download. This greatly expedites applet invocation (without sacrificing the dynamic and automatic applet version checking) and precludes the need for continual applet downloads across the Internet. Although it uses IBM’s firewall technology within the AS/400 to restrict access to the Web server, RVOS was not comfortable with the potential security risk of having its production AS/400 system directly accessible over the Web. The primary and justifiable fear was that of a hacker disrupting the mission-critical production host. To get around this, RVOS acquired a new AS/400 Model 170 in early 1999 — for the explicit purpose of acting as an Internet server for Web-based access. The low-profile, low-cost 170s, referred to by IBM as “E-servers,” are positioned as scalable alternatives to NT and UNIX boxes for E-commerce, Java, and Internet applications. As shown in Exhibit 8-3, all of the Web server, tn5250 server, and firewall software used by RVOS is a part of OS/400 and resides on the Model 170. This is another factor that simplified the overall implementation and kept costs to a minimum. At present, there is no direct connection between the production Model 510 and the Model 170. Data between the two systems is updated every night using tapes. This guarantees the isolation and security sought by RVOS. Wolfe plans to integrate the two systems to eliminate the need for data replication in the future. Web-based AS/400 access using the ResQNet tn5250 applet, replete with user interface rejuvenation, provided RVOS with the following advantages: • • • •

simple, straightforward, low-effort installation in a matter of days easy user interface rejuvenation with many automated features trouble-free, low-maintenance operation cost-compelling, Web-based access with no toll-call charges or the need for Remote Access Server equipment • ready extensibility in the future to support Secure Sockets Layerbased authentication and encryption • scalable, very-clean two-tier architecture that utilizes standard, highly proven, built-in components in OS/400 95

Exhibit 8-3.

ResQNet applet-based AS/400 access over the Internet, replete with customized and AutoGUI screens, as used by The Farmers Mutual Protective Association of Texas.

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

96

Real-Life Case Studies of Web-to-Host Integration RVOS is extremely happy with its Web-to-host solution. This is yet another resounding win-win situation for today’s Web-to-host technology. SABRE, INC. Sabre is synonymous with travel reservation systems. Sabre, which was American Airlines’ reservation system, was the pioneer in computerized reservation systems. Sabre, now an independent entity, is the world leader in electronic services and products for the travel and transportation industry. Just as with the above two case studies, this is yet another example of using browser-based SNA access over the Internet to provide agents with near-zero-cost remote access to data centers. However, this was not the only pivotal business driver in this instance. Sabre was also looking for a thin-client solution that would significantly minimize client software installation, upgrade, and maintenance costs. Sabre’s U.K. regional office in London needed a means to provide lowcost, low-maintenance remote access to some of its European travel agents. With some 2700 travel agents involved, spread across three countries, it was imperative that the access scheme chosen would not require installation and maintenance on a per-desktop basis — and that it was reliable, rugged, and intuitive so as to minimize training, support, and administration costs. In essence, Sabre required a thin-client, Web-to-mainframe solution. Sabre initially evaluated an NT-based solution but was unhappy with its reliability and manageability. It then turned to Novell’s HostPublisher — a highly scalable and feature-rich 3270-to-HTML conversion product that offers more value-added functionality (e.g., bona fide support for light pen operation) than any of its many competitors. Sabre started a pilot project using HostPublisher in mid-1998. Given its 1998 roots, the current implementation used by Sabre (as shown in Exhibit 8-4) is based on NetWare 4.11 and NetWare for SAA 3 — in essence, on release behind the versions available today. The current levels of these products are NetWare 5 and NetWare for SAA 4. Nonetheless, Sabre is ecstatic about the success of this Web-to-host project that uses straightforward 3270-to-HTML conversion to realize mainframe access. The beauty of such an HTML-centric solution is that the only software required on the client machines to realize host access is just a standard browser. 3270-to-HTML conversion is thus the “thinnest” of the thin-client solutions. This very thin-client host access was exactly what Sabre wanted. With this solution, there was no client-side software that had to be installed, regularly updated, or maintained. All of the travel agents being brought online already had a browser on their PCs through Windows 95. Consequently, nothing had to be done on or installed at the client machine. Everything required to achieve this browser-based mainframe access is self-contained on a server ovell NetWare server — in this case, a Novell NetWare server running NetWare for SAA and HostPublisher. 97

98

Exhibit 8-4. The Novell-centric 3270-to-HTML employed by Sabre, U.K.

98

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

Real-Life Case Studies of Web-to-Host Integration The staff and Sabre U.K. love the reliability and the rejuvenated “pointand-click” user interface. Sabre’s praise of 3270-to-HTML conversion can be paraphrased as: “It is colorful. It is point-and-click. It is pretty. And it works.” This HostPublisher solution has also proved to be extremely scalable. A test conducted in April 1999 showed that HostPublisher was handling around 4200 hits per hour. Also note that this PC server-based solution is expected to handle up to 2700 travel agents. With NetWare 5 and NetWare for SAA 4, this same configuration will be able to handle 4000 to 5000 concurrent sessions. CHARLESTON COUNTY COURT This case study clearly highlights how today’s Web-to-host integration technology — in particular, 3270-to-HTML conversion, which is the “thinnest” of thin-client solutions — can be effectively and profitably used to provide the general public with authorized access to public records. It also showcases this technology vis-à-vis local and state government applications. All forms of state and local government are extremely promising and receptive candidates for Web-to-host technology given that they are heavy users of mainframes and AS/400s — and moreover, have a public mandate, in many cases instituted as a high-profile election promise by the governor (or similar), for making as much of their information and services as possible Web-accessible. Since the overriding goal of such Web-to-host projects is to provide the general public with easy access to host data, the most germane technology, invariably, proves to be 3270/5250-to-HTML conversion. The Courts of Common Pleas and General Sessions for Charleston County in South Carolina take place at the Charleston County Judicial Center, located in North Charleston, South Carolina. These courts are part of the Circuit Court of South Carolina — where Charleston County in conjunction with Berkely County form the 9th Judicial Circuit of the state’s 16 circuits. The Court of Common Pleas is the civil branch of the circuit court and has jurisdiction over all civil cases in Charleston where the amount in dispute is in excess of $5000. The Court of General Sessions handles criminal cases — excepting most misdemeanor cases, which are usually heard in the Magistrates’ Court. Case records of the courts of common pleas and general session, as well as those of the small claims courts and out-of-county judgments, are deemed to be public domain information that the general public has a right to access and peruse. The clerk of court is responsible for maintaining and managing these records. Up until mid-1999, the general public, paralegals, or lawyers who required access to Charleston County legal documents or case records could only do so by actually visiting one of two county offices. This was obviously not that convenient — particularly for the average citizen — unless they happen to live or work close to one of these offices and are freely mobile. 99

APPLICATIONS FOR WEB-TO-HOST INTEGRATION The Charleston County Clerk of Court, Julie J. Armstrong, took it upon herself, earlier this year, to provide access to court documents over the Web. This online access to court documents and information is through the county court Web site (www3.charlestoncounty.org). Given that the case records were maintained on a mainframe, the Charleston County Court needed a sound and solid Web-to-host solution in order to realize its goal. The solution opted for, which has proved to be extremely successful, was Intelligent Environments’ feature-heavy and scalable ScreenSurfer offering that does 3270/5250-to-HTML conversion on-the-fly — replete with extensive user interface rejuvenation. See Exhibit 8-5. ScreenSurfer is a high-end 3270/5250-to-HTML conversion solution whose slew of attractive features include: 1. session integrity (i.e., persistence) and session time-out control through the use of cookies 2. function key support via an ActiveX applet 3. one-step light-pen selection through the use of clickable Graphical Interchange Format (GIF) tags 4. integrated Web server 5. support for Microsoft Active Server Page (ASP) technology for enhancing Web pages 6. optional user authentication 7. correct alignment of all host-generated columns and tables 8. support for at least 1000 concurrent sessions when installed on a typical NT-server configuration through extensive use of multi-threading Given this feature set, ScreenSurfer credibly competes with Novell’s HostPublisher and Eicon’s Aviva Web-to-Host Server for top honors in this arena — with the only caveat being that ScreenSurfer relies on ActiveX for some of its value-adds, thus becoming Windows-specific in some instances, whereas the other two use Java for their value-adds to realize platform independence. The Charleston County MIS Department was able to develop and deploy ScreenSurfer-based Web-to-host access in just eight weeks — and that included the extensive rejuvenation of quite a few mainframe screens. Today, ScreenSurfer is handling around 2800 mainframe access requests a day. (Charleston County Court currently has a license for 100 concurrent sessions.) This is another resounding success and endorsement for the power and simplicity of today’s Web-to-host technology. NAVARRE CORPORATION This exemplary case study shows how Web-to-host integration technology can be gainfully used to realize online E-commerce on a business-tobusiness basis across the Internet. E-commerce will exceed one trillion dollars per annum by 2002. Being able to effortlessly harness existing, highly proven, host-resident mission-critical applications via Web-to-host 100

Exhibit 8-5.

The Intelligent Environments’ ScreenSurfer-based architecture used by the Charleston County Court.

Real-Life Case Studies of Web-to-Host Integration

101

APPLICATIONS FOR WEB-TO-HOST INTEGRATION technology, à la this case study, to access E-commerce applications will expedite the adoption of E-commerce and reduce implementation costs by obviating the need to develop new software. Navarre Corporation, out of New Hope, Minnesota, is one of the largest distributors of consumer software, music, DVDs, and home videos to traditional retailers and the so-called “E-tailers.” Navarre, for example, supplies Amazon.com, one of the pioneers of E-commerce, with software. Navarre was one of the first companies to develop a Web site to facilitate business-to-business E-commerce à la an extranet application. Navarre, which does about $250 million in net sales at present, went public on December 16, 1993, on NASDAQ. Most of Navarre’s business transactions are E-commercebased and, as such, Navarre is heavily into electronic data interchange (EDI) and online supply chain management. Vendors who wish Navarre to act as a distributor of their wares have no choice but to conduct most of their dealings with Navarre electronically — typically through its navarre.com Web site. Navarre’s inventory tracking system is maintained on a mainframe — and outsourced at that. This case study shows how Navarre uses ICOM Informatics' Winsurf Mainframe Access (WMA) product to provide its vendors with access to the mainframe application. WMA offers both ActiveX-based tn3270(E) emulation as well as on-the-fly 3270-to-HTML conversion. In keeping with Navarre’s all-electronic philosophy, Navarre’s vendors are expected to ascertain their restocking needs and schedules online by interacting with Navarre’s inventory tracking application. This inventory tracking application is outsourced by Navarre to a neighboring company — Scicom in Minnetonka, Minnesota. Exhibit 8-6 shows the architecture of the WMA-centric solution adopted by Navarre. The WMA server in the Scicom data center is configured such that vendors using Internet Explorer on a PC will realize their access via the ActiveX emulator, while users of all other platforms (in particular, Macs) will rely on WMA’s 3270-to-HTML conversion to achieve their mainframe access. Although SSL-based security is available for the ActiveX-based access via the Winsurf Security Server, this option is currently not used by Navarre. Navarre’s in-house administrators, however, do use the security server for all their interactions. Scicom, which acts as the outsourcer for this application, also per chance happens to be an ICOM distributor. With some help from ICOM (United States), Scicom implemented this WMA access scheme as a turnkey solution for Navarre as a part of the outsourcing agreement. This WMA solution has now been active for quite awhile and is heavily used — with the system being extremely stable and reliable. This case study also demonstrates that applet-based emulation and 3270/5250-to-HTML, rather than being mutually exclusive approaches, are oft-times complementary solutions that should be used in tandem to 102

Exhibit 8-6.

Navarre’s outsourced inventory tracking mainframe application that is accessed by various vendors to check their restocking needs using ICOM’s Winsurf Mainframe Access (WMA).

Real-Life Case Studies of Web-to-Host Integration

103

APPLICATIONS FOR WEB-TO-HOST INTEGRATION address different categories of users: for example, power users versus casual users, intranet users versus Internet users, and data entry users versus enterprise resource processing (ERP) users. THE CHICKERING GROUP The Chickering Group, based in Cambridge, Massachusetts, provides a great example of a fast striding corporation that is gainfully exploiting a highly secure, three-tier, Web-to-AS/400 integration over the Internet to rapidly expand its customer base by offering a zero-lead-time access solution. Moreover, by implementing this Web-based AS/400 access solution in 1997, The Chickering Group became one of the very early adopters of Web-to-host integration. The Chickering Group is a leading provider of health insurance products and services to students pursuing higher education. In 1999, it was providing insurance to approximately 220,000 students spread across more than 120 college and university campuses around the United States. Health insurance in general, and student health insurance in particular, is a highly competitive and price-sensitive industry. Health insurance providers such as The Chickering Group are thus continually and aggressively looking at means to reduce costs, improve efficiency, provide more services, and be more responsive to the changing needs of their clientele. Consequently, corporations such as The Chickering Group are highly motivated and unhesitant when it comes to regularly reengineering their business processes to garner all possible benefits from promising new technology. The spread of the Internet and the availability of technology to enable browser-based access to SNA applications running on AS/400s provided The Chickering Group with a wonderful opportunity to reduce its operational costs, while at the same time significantly increase its reach into the student population. Whenever possible, The Chickering Group has tried to provide universities and colleges with the ability to remotely access its AS/400-centric computing system to obtain realtime information on its insurance plans, insurance coverage, and insurance participant data. Such remote access was originally provided via either dial-up systems or leased point-to-point connections in the case of the larger institutions. Offering this type of remote access is a relatively expensive proposition — particularly as the number of remote sites that have to be supported starts to increase at a rapid clip. The cost issues become even more exacerbated if the client base at some of the remote sites is relatively small. The lead-time required to provide a connection to the customer was also increasing and approaching three to four weeks. What The Chickering Group desperately needed was an alternate means of providing remote access that was flexible, scalable, cost-effective, and secure — and furthermore did not require much set-up at the data center, thus minimizing the time taken to bring a new customer online. The Internet proved to be the ideal solution, particularly since all of 104

Real-Life Case Studies of Web-to-Host Integration its clients, being academic institutions, already had excellent access to the Internet. Using browser-based access over the Internet, The Chickering Group could cost-effectively and securely connect its branch office employees and its scholastic clients to its AS/400-centric health care insurance system. The Chickering Group opted for a three-tier Farabi HostFront solution, given that Farabi Technology is a major provider of AS/400 access solutions. The architecture of the AS/400 access scheme used by The Chickering Group is shown in Exhibit 8-7. The configuration as shown in Exhibit 8-7 is currently constrained to 128 concurrent sessions. As their client base grows, The Chickering Group is planning to install another server to double this capacity. Farabi will use a Microsoft-supplied Windows NT utility to load-balance the applet TCP connections between the two servers. When clients or remote-site employees connect to The Chickering Group’s home page, they are presented with a user-friendly menu that provides an option to access either public domain information or the company’s internal secure site. If the latter option is chosen, HostFront authenticates the user, downloads a Web-based thin-client interface, in the form of a Java applet or ActiveX control, and then establishes a secure end-to-end connection. Once this connection has been established, the remote Web browser users are able to initiate secure AS/400 host sessions over the Internet. THE BOTTOM LINE These six real-life case studies conclusively demonstrate that Web-tohost integration technology is indeed very real, proven, stable, and more than ready for prime time. These six case studies were explicitly chosen to show the diversity of solutions that are possible and the wide spectrum of applications that can be addressed with today’s Web-to-host technology. The two case studies pertaining to providing insurance agents with access to host applications, viz., Lafayette Life and RVOS, show how the same successful end result is achieved using two very disparate techniques — 3270-to-HTML conversion by Lafayette Life and Java-applet based tn3270(E) emulation in the case of RVOS. The Navarre case study that showcases E-commerce and business-to-business interactions over the Web, on the other hand, uses both of these techniques in parallel. The Sabre and Lafayette case studies both prove that this technology can indeed be scalable, given that both configurations support over a thousand concurrent sessions. The bottom line is thus very simple and straightforward: Web-to-host integration technology can be very profitably used in conjunction with mission-critical applications and, as demonstrated by these case studies, is indeed being actively used in such scenarios already.

105

Exhibit 8-7.

The architecture of the Farabi HostFront-centric AS/400 access solution being used by The Chickering Group.

APPLICATIONS FOR WEB-TO-HOST INTEGRATION

106

Section II

Web-to-Host Access Technologies PRIOR TO THE ADVENT OF THE WEB, END USERS ACCESSED LEGACY SYSTEMS using either fixed-function terminal devices or a PC/workstation equipped with special-purpose terminal emulation software, or by accessing a special middleware gateway device that communicated directly with the host application or data. Web-to-host solutions allow end users to access host systems using a Web browser as the primary user interface or point of access. Beyond that commonality, however, there are a variety of different approaches and technologies for providing Web-based access to host systems. This section covers the dominant technologies for Web-to-host access. Chapters 9 and 10 provide overviews of the types of technologies utilized for Web-to-host access. One key difference between approaches is whether the approach is a thin-client approach or a zero-client (i.e., server-centric) approach. Chapters 11 through 13 describe the key thin-client and serverbased Web-to-host technologies. Chapter 14 discusses how the emerging Web technology, XML, can be utilized to build new E-commerce applications that integrate with legacy systems.

107

Chapter 9

The Enterprise Intranet Series: Web-to-Host Technology Gary Tyreman

SEVERAL YEARS AGO, WE WROTE THE INDUSTRY’S FIRST WHITE PAPER ON THE INTRANET, entitled “The Intranet: Implementation of Internet and Web Technologies In Organizational Information Systems” (http:// www.hummingbird.com/whites/intranet.html). The embryonic state of the Internet gave us license to elaborate on the potential use of Web technologies in business and organizational environments. The discussion was based on the premise that the enabling technologies of the Web — TCP/IP, HTTP/CGI, and HTML — would form the foundation of sophisticated business information systems now called intranets. Since then, the success of Internet and Web technologies in facilitating the development of information systems has been astounding. The Web browser rapidly emerged as the universal interface to organizational information, and Web servers have become pillars of electronic commerce. In addition to their origin as open systems technologies, a major factor in the widespread adoption and success of Internet and Web technologies is their inherent simplicity. Web technologies are relatively easy to understand and implement, and the browser provides one of the most simple and intuitive graphical user interfaces ever designed. Simplifying user access to often overwhelmingly complex networked computer environments is a key motivation of all information technology managers, especially when they are faced with providing new or remote users, customers, vendors, or other business partners with access to organizational information via the Internet — what is now being called an extranet.

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

109

WEB-TO-HOST ACCESS TECHNOLOGIES Organizations are now realizing the limitations of early Web technologies as they begin to evaluate and pilot Web-to-host connectivity. Although the browser may be the future lens for viewing organizational information, the foundation technologies of the Web, HTTP, CGI, and HTML were not designed for business-critical environments. As a result, many of today’s Web-to-host technologies pioneered using HTTP/CGI and HTML are firstgeneration products, characteristic of an emerging technology market. FIRST-GENERATION WEB-TO-HOST PRODUCT ISSUES First-generation Web-to-host product issues include: • the stateless nature of HTTP, which does not support the stateful protocol streams characteristic of business-critical applications hosted on the mainframe or UNIX systems that are the backbone of enterprise computing • the display limitations of HTML, which, for example, make it difficult to reproduce the interface familiar to users (e.g., 3270 terminal screens) and cause the retraining that browser-based interfaces are intended to eliminate • the bottlenecks and consequent lack of scalability imposed by the Common Gateway Interface (CGI), which must launch a new process on the server for every client request • the insecurity of CGI, which can expose servers to a wide range of attacks Nowhere are these issues more pressing than in the burgeoning field of Web-to-host connectivity, which promises to deliver access to legacy enterprise information resources through a simple browser-based interface. Although Web-to-host technology is thought to have a bright future, the market is currently dominated by fear, uncertainty, and doubt as dozens of vendors strive to convince IT managers that their solutions are the best. In fact, at present there are almost as many different Web-to-host approaches as there are vendors. Adding to the confusion of the Web-to-host market is the new computing paradigm of distributed object-oriented computing. This new computing model portends a computing environment both more functional and more complex than client/server computing, which has served us so well. Based on object-oriented technologies, distributed computing brings to the table Java, CORBA/IIOP, and other enabling technologies that have the potential to facilitate enterprise-strength Web-to-host connectivity in business-critical environments. The primary objectives of this chapter are to identify the major issues involved with implementing enterprisewide Web-to-host solutions, and to serve as a reference on Web-to-host connectivity solutions. 110

The Enterprise Intranet Series: Web-to-Host Technology THE PROMISE OF WEB-TO-HOST TECHNOLOGY Today, more than 70 percent of all corporate data resides on the mainframe and is primarily accessed through PC-based terminal emulation or fixed-function devices such as 3270 terminals. Web-to-host technology promises to provide easy, secure local and remote access from a wide range of devices, including PCs, workstations, terminals, network computers, and even hand-held devices. Perhaps one of the greatest benefits of Web-to-host technology is providing intranet users and remote workers with easy access to data residing on mainframe and midrange systems. Many organizations are just now beginning to realize the business-to-business potential of Web-to-host technology in providing their customers and business partners with Internet and extranet access to enterprise data. WEB-TO-HOST BENEFITS The benefits of Web-to-host technology include: • browser simplifies user interface and navigation • ease of access for remote users and customers via the Internet, intranet, and extranet • reduced management burden and lower cost of software ownership — software maintained on server — eliminates need for desktop software configuration and installation — desktop maintenance involves only browser or JVM (Java Virtual Machine) and OS upgrades THE IT MANAGER’S TECHNOLOGY PERCEPTION REALITY CHECK In an effort to gain a realistic assessment of the state of any technology, many IT managers undertake what has been called a technology perception reality check (TPRC). The TPRC process usually involves discussions with other IT managers and market researchers. When TPRC is applied to the Web-to-host market, some important verities emerge: • There is a long-term desire to integrate the Internet, intranets, extranets, and enterprise internetworks into a cohesive environment that facilitates easy access to business-critical applications and information. • IT managers are seeking solutions that will provide both casual and dedicated host access to a growing number of new local and remote users via a browser. • IT managers are challenged by the management issues associated with installing and configuring host access software on the personal computer desktop. • IT mangers are challenged by the management issues associated with installing, configuring, and managing host access software on servers and gateways. 111

WEB-TO-HOST ACCESS TECHNOLOGIES • Currently, there is no single standard network object model (NOM) infrastructure to support distributed object-oriented computing. The industry is migrating toward next-generation network products at a quickened pace according to a recent IDC report that states that Web-tohost browser-based client licenses will account for more than 80 percent of host access revenue by 2003. According to the Gartner Group, “Web-to-host access will increase by 2002 [because] the number of individuals who access the host on an occasional basis will increase by an order of magnitude… In 2000, enterprises should develop a strategy to implement Web-tohost products within the next 24 to 36 months or risk missing significant business benefits and losing control of the technology to individual business units.” TYPES OF WEB-TO-HOST SOLUTIONS Despite the early status of Web-to-host technology, there are many Webto-host solutions on the market today, mostly designed for access to mainframe, midrange, and UNIX systems. In 1997, several vendors (including Hummingbird) announced support for X11R6.3/6.4 (Broadway), the latest release of the X Window System. Broadway is a Web-to-UNIX host solution that allows UNIX/X applications to be accessed over the Internet and viewed within the browser interface by enabling X display servers to function as browser plug-ins. The list below describes the eight predominant Web-to-host models that have emerged over the past several years. Mainframe and Midrange Web-to-Host and Thin-Client Solutions • Web server on mainframe: browser connects directly to the mainframe or midrange via HTTP/HTML and does not employ a gateway • HTML gateway to mainframe: browser connects to gateway, which connects directly to mainframe via SNA or TCP/IP, which converts data on the fly to HTML • Java/ActiveX applet (direct connection): browser connects directly to mainframe or gateway via Java or ActiveX applet downloaded from a Web server • Java/ActiveX applet (gateway connection): browser connects to gateway server via Java or ActiveX applet downloaded from the gateway or Web server; gateway maintains the connection to mainframe or other host • X11R6.4 (“Broadway”): consortium-developed technology allows UNIX/X applications to be accessed over the Internet and viewed within the browser interface, by enabling X display servers to function as browser plug-ins • Proprietary Middleware: “all-in-one” development environment, proprietary server, and proprietary client 112

The Enterprise Intranet Series: Web-to-Host Technology • Proprietary Application Broker: server-based application broker utilizes proprietary protocol for distributing presentation layer of applications, which is converted to Java applets on-the-fly • Proprietary Application Server: Windows NT application server utilizes proprietary protocol such as Citrix’s ICA or Microsoft’s RTP to distribute presentation layer of application to desktop thin client Enterprise Web-to-Host Implementation Issues IT managers are just beginning to deal with many of the rudimentary issues involved with Web-to-host implementations, such as performance, functionality, feature sets, security, licensing, and concurrency, among others. First-generation Web-to-host solutions have limited functionality compared to today’s fat clients. Although many solutions promise reduced cost of ownership by centralizing desktop management issues using Web servers, many of these solutions are still building in fault tolerance and enterprise scalability, which are just beginning to build in the tools and utilities required to authenticate and secure users. Indeed, many of the issues identified in the following list and Exhibit 9-1 are still being addressed, or even piloted in enterprise environments. • Manageability: application management moves to the server as applications (applets) reside on hundreds of servers rather than tens of thousands of desktops • Scalability: providing Web-to-host services to 20,000 desktops is challenging and HTML-based solutions offer limited scalability and load balancing becomes a primary concern • Security: authentication of users and secure access to hosts, from within the intranet and over the Internet, are challenging issues • Licensing and metering: licensing and metering utilities are required to assess software usage and concurrency from distributed servers • Version control: upgrades, especially in applet-based solutions, must be controlled to avoid server/network overload and manage retraining effectively • Configuration: management of gateways and servers and hosts involves hardware and software issues, depending on the level of access • Performance: high-performance access to the host and delivery of additional functionality from distributed components and servers • Desktop: the desktop will require adequate horsepower to run Java applications and a current version of the Java Virtual Machine • Desktop: HTML conversion is not efficient due to the stateless nature of HTTP • Desktop: caching strategies for preserving network bandwidth from the impact of multiple, duplicative applet downloads • Desktop: JVMs vary across platforms and are only available for 32-bit OS 113

WEB-TO-HOST ACCESS TECHNOLOGIES Exhibit 9-1. Web-to-host solutions and their issues. Web-to-Host Solution Host Web server HTML gateway Java applet (direct connection) ActiveX applet (direct connection) Java/ActiveX (gateway connection) Proprietary middleware Proprietary application broker Proprietary application server

Issue(s) Consumption of host cycles and TCP/IP connections Not stateful, no desktop integration APIs, limited scalability Performance, server functionality, and services Proprietary, platform specific, security, applet size large As above, plus limited scalability Proprietary, limited extranet applicability Proprietary, limited extranet applicability, limited scalability Proprietary, limited scalability

Each of the models listed has its own set of issues and are briefly outlined in Exhibit 9-1. Web-to-Host Desktop Issues Profiling user needs and expectations is perhaps the most fundamental desktop issue that must be addressed before implementing a Web-to-host solution. Currently, IT managers are interested in implementing Web-tohost solutions on the desktops of new, casual, or remote users, in addition to customers and business partners who may need remote access to enterprise databases for checking inventory or ordering products. Establishing tailored user profiles for these groups is key to determining whether a Webto-host solution is appropriate. In many cases, users who demand business-critical connectivity are accustomed to a high degree of functionality and may not be satisfied with browser-based solutions. In addition, organizations will undoubtedly deploy a combination of traditional and thin clients within the enterprise to meet differing needs. Web-to-host desktop issues include: • • • • • •

user profile and requirements traditional client versus thin client performance functionality and feature sets support for legacy scripts and APIs security, HTTP, and Java implementations

In addition to providing browser access to legacy data and applications, eliminating desktop software or traditional clients is a motivation for IT managers who are considering Web-to-host solutions. Client-less desktops will ultimately lead to the “promised land” of reduced cost of ownership, with a few outstanding desktop management issues (see Exhibit 9-2).

114

The Enterprise Intranet Series: Web-to-Host Technology Exhibit 9-2.

Important Web-to-host desktop considerations.

Browser Support (Level and Revision) JVM support JavaBeans support Initial applet size and functionality JAR and CAB support Sandbox limitations with Java

Terminal Emulation Supported Support for SSL SOCKS support PC requirements (RAM, CPU, etc.) OS deployed Push support

JAVA AND CORBA/IIOP: THE MISSING LINKS Like client/server computing before it, Web-to-host technology reflects an ongoing industry trend toward the dispersement or decentralization of computing resources. Perhaps the ultimate manifestation of this trend is distributed object-oriented computing, in which application functionality is “componentized,” so that, ideally, only the capabilities needed for a given task are present at the time needed. For example, in the Java applet Web-to-host model, this means that a user desiring to access information stored on an IBM System/390 mainframe would receive only 3270 functionality, rather than a full-featured applet that would consume more resources than necessary to address the task at hand. The goal, of course, is more efficient use of computing resources. But this vision of distributed computing requires a technological infrastructure that enables software components (objects or application “fragments”) to seamlessly interoperate and share their capabilities, regardless of their location within the enterprise. This infrastructure is supplied by the combination of the Common Object Request Broker Architecture (CORBA) and the Internet Inter-Orb Protocol (IIOP), supported by the Java programming language. These are the missing links needed to create enterprise-strength Web-to-host products. Although it is still in the early development stages, Java provides a rich platform for business-critical application development that incorporates the browser and its Java Virtual Machine as a universal interface for cross-platform connectivity. Interoperability and interapplication communications are the promises of CORBA/IIOP-based distributed object-oriented computing, wherein object brokers enable software components to find each other, discover the services available from each other, and inter-operate, while IIOP enables ORBs from competing vendors to cooperate. This not only conserves desktop resources by enabling only the functionality needed for a task to be located, downloaded, and executed, but also eliminates the HTTP/CGI bottleneck on middle-tier servers by substituting multithreaded objects that scale far more gracefully.

115

WEB-TO-HOST ACCESS TECHNOLOGIES The level of application integration and functionality promised by Java and distributed object-oriented computing extends far beyond what is possible in today’s client/server computing environment. Within the CORBA/IIOP-based three-tier architecture, applications become objects or components resident on servers, and once downloaded to the desktop, they can be used to deliver a wide range of services. Moreover, these objects can communicate with each other, delivering a synergy of interaction that delivers as much or more functionality as a monolithic application with far more efficient use of desktop, server, and network resources. These capabilities can be further enhanced by employing push technology to deliver specific information on demand to the desktop, and to check on the status of applets and objects. Enterprise Benefits and Capabilities of Java, CORBA, and IIOP • Java: The language of object computing, Java is open, platform independent, and multithreaded. It promises significant reduction in the cost of software development and ownership by leveraging development across multiple platforms and reducing desktop/client management and overall administration. • CORBA: An enterprise scalable network object model that specifies how objects (applets) should interact while they act as services. • CORBA: Supports legacy systems and application integration through its Interface Definition Language (IDL). • CORBA Services Architecture includes: — licensing, properties, and query services — security and time services — transaction, concurrency, relationships, and externalization services — persistence, naming, event, and lifecycle services — trading, collections, and start-up services • Internet Interoperable ORB Protocol (IIOP): Facilitates ORB-to-ORB communications and the delivery of application services over TCP/IP. Combined with a CORBA/IIOP-based network object model (NOM), Java applets and applications have the ability to spawn stateful protocol streams over TCP/IP, enabling functionality and interoperability between the desktop and the host that is not possible with proprietary or HTML/CGI-based client/server architectures. WEB-TO-HOST SECURITY Security is one of the most pressing concerns confronting IT managers, but one that has received scant attention in the emerging Web-to-host market. Security technologies needed to protect Web-to-host sessions against attack are themselves still immature, and corporations are inclined to distrust any technology until someone else has taken the risk of proving it. 116

The Enterprise Intranet Series: Web-to-Host Technology This concern will only become more pressing as distributed objectoriented computing matures, leading to systems where objects play the role of both server and client, interact in ways impossible to predict, and evolve dynamically in response to changing conditions. Yet, to avoid crippling the potential of a distributed object-oriented system, it will be necessary to give both trusted users and objects transparent access to all other objects, in effect maintaining the illusion of a single system. In general, whether in present-day systems or the fully distributed systems of the future, security is traditionally held to involve four parameters: • authentication: guaranteeing that the client or server is who or what it claims to be • confidentiality or privacy: guaranteeing that messages cannot be intercepted and read • integrity: guaranteeing that a message is received exactly as sent • non-repudiation: making it impossible for the sender to deny having originated a message A fifth parameter might be added when dealing with servers that execute programs in response to requests from clients: • Functional boundaries: the server will only execute valid and acceptable commands For Web-to-host security, these parameters apply to communications between all parts of the system, protecting the host, the middle tier (if any), and the client. Leaving any of these areas exposed causes the entire system to be vulnerable; however, a full survey of security technology is beyond the scope of this chapter. Web-to-Host Security Today Many security technologies are still embryonic, so their presence or absence cannot be used as a metric for choosing a Web-to-host solution. More important is the presence of a viable migration path from the security measures used in existing systems to the security implementation in the proposed Web-to-host solution. Beyond that, the scalability of a security technology is a primary consideration. SUMMARY Many of the issues encountered with first-generation Web-to-host solutions will most likely be resolved with the advent of distributed computing and the further maturation of Java. The promise of distributed object-oriented computing and thin clients includes reduced cost of software development and ownership, through interoperability and the elimination of desktop software installation and configuration. The leap from client/server to 117

WEB-TO-HOST ACCESS TECHNOLOGIES distributed object-based computing is perhaps one of the most significant technology transitions that many IT organizations will undertake. This transition will be significantly impacted by fundamental infrastructure decisions such as what network object models (CORBA or DCOM) will be employed to support distributed object-based computing. As Web-to-host evolves, third-party translation software may make the differences between CORBA and DCOM a moot issue. It is key to remember that the implementation of server-based Web-to-host technology is a strategic enterprisewide decision in business-critical environments. Additional Reading 1. Mowbray, Thomas and Ruh, William, Inside CORBA, Addison Wesley, 1997. 2. Orfali, Robert; Harkey, Dan; and Edwards, Jeri, Instant CORBA, John Wiley & Sons, 1997. 3. Orfali, Robert; Harkey, Dan; and Edwards, Jeri, The Essential Distributed Objects Survival Guide, John Wiley & Sons, 1996. 4. Rubin, Aviel; Geer, Daniel; and Ranum, Marcus J., Web Security Sourcebook, John Wiley & Sons, 1997. 5. Taylor, David, Object Oriented Technology: A Manager’s Guide, Addison Wesley, 1990. 6. Wang, Yun and Young, Tom, Distributed Object Infrastructures, INFOWORLD, October 20, 1997, pp. 90-96. ©1999 Hummingbird Communications, Ltd.

118

Chapter 10

Web-to-Host Connectivity Tools in Information Systems Nijaz Bajgoric

IN

INFORMATION TECHNOLOGY

(IT)

HISTORY, THE INVENTION OF THE

graphical user interface (GUI) was a revolutionary step in improving both the efficiency and effectiveness of IT end users. The GUI has become dominant not only in operating systems, but also in application software. After introducing Web technology in 1994, it turned out that a Web browser is the most convenient way of using computers for end users because it is completely based on a mouse-click operation. Of course, this became possible thanks to HTTP, HTML, and other Internet/Web-related facilities. The job of IT people, both IT vendors and IS staff, in organizations is to make information technology seamless and easy, so that end users can do their jobs as easily and efficiently as possible. From the perspective of ease of use, it is the Web technology that can help in that sense. Web-to-host connectivity tools are software products that ease the process of connecting to several types of host data (also known as legacy data), both from end users and state-of-the-art client/server (c/s) applications. FRAMEWORK FOR IMPLEMENTATION OF WEB-TO-HOST ACCESS TOOLS Today, Web technology can be used in contemporary information systems (IS) in three modes: 1. for Internet presence, intranet and extranet infrastructures 2. for improving access to corporate data, both legacy and c/s applications 3. for rapid application development

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

119

WEB-TO-HOST ACCESS TECHNOLOGIES Also, Web technology can significantly cut the costs of accessing systems and reduce the time required to connect users to corporate data. The role of Web technology in improving data access can be considered from the following perspectives: • End-users’ perspective: with the main objective defined as how to provide end users with efficient access to corporate data • Application developers’ perspective: how to improve applications’ efficiency using: – Web technology in creating middleware and gateway applications that provide more efficient access to the existing applications (legacy data and c/s apps) – Web technology in development of Web-enabled c/s applications with the primary aim to provide a “thinner” client side (based only on Web browser) – Web technology in creating dynamic Web pages for corporate intranet and extranet infrastructures (dynamic HTML, ASP, etc). Exhibit 10-1 represents a framework for implementation of Web-to-host connectivity tools in an information system (IS). The IS subsystems that can be accessed via Web technology are: • transaction processing system, which usually consists of legacy data and c/s data • messaging system • document management and workflow system • business intelligence system • ERP system (if IS infrastructure is based on an integrated ERP solution) The remainder of this chapter provides some examples of Web-to-host tools that connect to these systems. WEB-TO-LEGACY DATA According to a recent study (http://www.simware.com/products/salvo/articles_reviews/linking.html), about 80 percent of all enterprise data is in legacy data structures, and rules for access are within legacy applications. The Gartner Group (www.gartner.com) also estimates that 74 percent of all corporate data still resides on legacy mainframes. Legacy systems (legacy data or legacy applications) refer to older or mature applications that were developed from the late 1950s to the early 1990s. Such systems are primarily mainframe systems, or distributed systems where the mainframe plays the major processing role and the terminals or PCs are used for application running and data uploadingdownloading. 120

Web-to-Host Connectivity Tools in Information Systems

Exhibit 10-1.

Framework for implementation of Web-to-host connectivity tools.

Access to legacy data through user-friendly applications (standard c/s applications and Web-based applications for intranets and the Internet) requires a processing layer between the applications and the data. Web-tohost technology makes it possible for users to access the data stored on legacy hosts just by clicking a Web link. Moreover, it cuts the costs of software ownership through centralized management. Example: WRQ Reflection EnterView (www.wrq.com). Reflection EnterView is a Java-based legacy host access program from WRQ. As can be seen from Exhibit 10-2, it gives users easy access to IBM, UNIX, and Digital hosts — right from their desktop browsers. Example: Network Software Associates’ Report.Web (www.nsainc.com). R e port.Web is another Web-to-legacy program and intranet report distribution 121

WEB-TO-HOST ACCESS TECHNOLOGIES

Exhibit 10-2.

WRQ Reflection EnterView.

tool from Network Software Associates, Inc. At the heart of Report.Web is the enterprise server, a powerful and robust engine that automates the entire process of delivering host-generated reports to the Web — from almost any host, including IBM mainframes, AS/400s, DEC VAXs, and PC LAN servers, to the corporate intranet/extranet. Report.Web provides a variety of Web-accessible outputs, including: • • • • •

spreadsheet output WRF (Web reporting format) output HTML output PDF output thin client (all reports published by the enterprise server are readable by standard Web browsers)

See Exhibit 10-3. Report.Web also supports distributing ERP-generated reports across the corporate intranet, without deploying ERP clients at every desktop.

122

Web-to-Host Connectivity Tools in Information Systems

host

web reports

REPORT.WEB Exhibit 10-3.

Network Software Associates ReportWeb.

WEB-TO-MESSAGING SYSTEMS Example: Web-to-Mail (www.mail2web.com). The Web2Mail or Mail2Web program is a service that lets users use their POP3 e-mail accounts through an easy Web interface. If this program is installed on the server side (SMTP server), then the only program users need on the client side is a Web browser. They do not need any e-mail program like Eudora, Pegasus, MS Exchange Client, MS Outlook, or character-based telnet-pine program. From the end-users’ perspective, this is very important because the Web browsers’ GUI is based on a very simple “point-and-click” interface. Hence, this approach is more user friendly. As an example, Mail2Web’s URL address is a public site that allows people to use a Web-based interface to their e-mail accounts (for those SMTP servers without the Web2Mail program). See Exhibit 10-4. Example: Web-to-Fax (http://www-usa.tpc.int ). T h e We b 2 F a x p ro g r a m , which is very similar to Web2Mail, gives an opportunity of sending and

123

WEB-TO-HOST ACCESS TECHNOLOGIES

Server Name: User Name: Password: Check Mail

Exhibit 10-4. Web2Mail interface.

receiving fax documents from Web browsers with no additional software (see Exhibit 10-5). WEB-TO-DOCUMENT MANAGEMENT AND WORKFLOW SYSTEMS Web-based Index-Search Tools Example: Microsoft Index Server (www.microsoft.com). M i c ro s o f t I n d e x

Server is the Microsoft content-indexing and searching solution for Microsoft Internet Information Server (IIS) and Peer Web Services (PWS). Index Server can index documents for both corporate intranets and for any drive accessible through a uniform naming convention (UNC) path on the Internet. Users can formulate queries using the Web browser. Index Server can index the text and properties of formatted documents, such as those created by Word or Excel (see Exhibit 10-6). Even the Office97 package includes Web-searching facilities. Its Web Find Fast is a search utility that allows a Web server to search HTML files and summary properties of Office97 documents (Author, Title, Subject, etc.) (see Exhibit 10-7). Example: Compaq’s AltaVista Search Intranet (http://altavista.software.digital. com/). AltaVista Search Intranet is search and retrieval software that pro-

vides search and retrieval for information in several formats, including HTML, Microsoft Word, Adobe PDF, and many other formats (over 150) of files located on Internet and intranet Web servers, Lotus Domino Servers, and Windows LANs. AltaVista Search also includes multi-national support (see Exhibit 10-8). Web-Enabled Document Management and Workflow Software Example: Keyfile from Keyfile Corporation (www.keyfile.com). Keyfile document management application provides Web-based access to user documents. It also supports integration with Microsoft Exchange/Outlook 124

Client Software

Server Software

?

Questions and Answers

Other Languages: English Italian Czech German

Send A Fax

Exhibit 10-5. Web2Fax interface.

Remote Printing WWW Interface

Check Coverage

How?

Web-to-Host Connectivity Tools in Information Systems

125

WEB-TO-HOST ACCESS TECHNOLOGIES

Index Server Search Form - Microsoft Internet Explorer File

Edit

Back

View

Go

Favorites

Forward

Stop

Help

Refresh

Home

Search Favorites

Print

Address

Links

Index Server

Enter you query below. systems management

Execute Query

Clear

Query Syntax Help

Exhibit 10-6. Microsoft Index Server.

messaging system. The client side does not need any extra software installed beyond a Web browser (see Exhibit 10-9). Example: FileNET Panagon and Waterflow (http://www.filenet.com). FileNET

Panagon is enterprisewide integrated document management software that represents a solution for capturing, accessing, managing, utilizing, and securing business information. Information is also available via Web interface (see Exhibit 10-10). Example: SAP Internet-Based Workflow (www.sap.com/internet/index.htm).

SAP Business Workflow module is another example of a Web-enabled workflow management system. With SAP Business Workflow, a user can initiate a workflow (via Internet/intranet application components, BAPIs, forms),

Web Find Fast Advanced Search

Help

In the box below, type the search terms you would like to match.

Words or phrases in the document: Search

Return up to 10

documents at a time.

Exhibit 10-7. 126

Microsoft Office97 Web Find Fast.

Reset

Web-to-Host Connectivity Tools in Information Systems

Intranet

World Wide Web

Novell

®

File Servers

Extranet

Microsoft

®

TM TM

Seach Intranet 97

Exhibit 10-8. Compaq AltaVista Search Intranet.

track his or her work via the Internet application component “Integrated Inbox,” respond to requests for other users, or review the workflow history via the Internet application component “Workflow Status Reports.” WEB-TO-BUSINESS INTELLIGENCE SYSTEMS Browser-based access to so-called business intelligence systems (decision support systems, executive information systems, data warehousing systems, etc.) is very important for decision-makers because of its ease of use.

Keyfile Via the Internet URL links to the Keyfile "Workspace" may be mailed or embedded in web pages to share Keyfile document objects in collaborative applications. This allows organizations to access their Keyfile "Workspace" from a remote location, over the internet.

Exhibit 10-9. Keyfile Web-based interface.

127

WEB-TO-HOST ACCESS TECHNOLOGIES

RE JE CT ED

0 MDD Number___________________Rev. ___________ 91-VAM095

15 Page 2 of_____

MDD IMPLEMENTATION APPROVAL:

RESPONSIBLE ENGR: iNDEPENDENT REVIEWER ENGINEERING SUPV: mGR ENGR SUPPORT: PRB REVIEW/GMNP APPROVAL REQUIRED FSAR CHANGE REQUIRED

YES[

]

NO [x]

APPROVAL IS REQUIRED! YES[

]

NO [x]

]

NO [x]

TECH SPEC CHANGE REQUIRED PRB MEETING NO.

N/A

YES[ DATE

N/A

PRB CHAIRMAN

Exhibit 10-10. FileNET Panagon.

Web-Enabled Desktop DSS Tools Decision modeling is now available via the Web browser. The decisionmaker can use a model that is already created and stored on a server from his or her computer through the Web browser. Example: Vanguard DecisionPro Web Edition (www.vanguardsw.com). T h e Web version of DecisionPro, a powerful desktop DSS tool, allows decisionmakers to run DecisionPro models remotely. They do not need special software on their computers other than a standard Web browser. For example, a model developed to assist salespeople in determining prices dealing with customers can be installed on a server and run remotely on a salesman’s notebook computer.

What follows is an example of “loan qualification model,” a model developed with DecisionPro and accessed through the Web browser. Users explore information with a browser so there is no client software to deploy (see Exhibit 10-11). Web-Enabled EIS (Reporting) Executive information systems (EIS) or reporting applications provide user-friendly access to corporate data. These applications are usually DBMS-based and can contain both direct data from c/s applications or 128

Web-to-Host Connectivity Tools in Information Systems

Candidate's annual income?

Sufficient Income Unevaluated

Income Unevaluated Principal Unevaluated Age Unevaluated

Qualify Unevaluated

Stable Unevaluated

Married Unevaluated Job Tenure Unevaluated

Adult Unevaluated

Next

Exhibit 10-11.

Age Unevaluated

Cancel

Web-based modeling feature of DecisionPro.

extracted and converted data from legacy systems. This conversion can be done manually or automatically through middleware or gateway programs (e.g., ISG Navigator, http://www.isg.co.il/home.asp). Example: Cognos Impromptu Web Reports (www.cognos.com). Cognos Impromptu Web Reports delivers reporting facilities over the Web, providing end users with quick and easy access to the latest company reports — directly from their browser (see Exhibit 10-12).

Web-to-Enterprisewide DSS In addition to Web access to desktop DSS tools, such GUI interfaces are supported by enterprisewide decision support systems as well. Example: Business Objects WebIntelligence (www.businessobjects.com).

Business Objects’ WebIntelligence is a multi-tier, thin-client decision support system (DSS) that provides end users with ad hoc query, reporting, and analysis of information stored in corporate data warehouses (see Exhibit 10-13). Example: MicroStrategy’s DSS Web (www.strategy.com). MicroStrategy DSS Web is a user-friendly interface that connects corporate data warehouse across the World Wide Web (see Exhibit 10-14). 129

130 Format PDF

PDF

PDF

Updated Actions

Exhibit 10-12. Cognos Impromptu Web Reports.

Channel deployed at 05/15/98 17:02:05

Channel

PDF DrillToProduct DrillToProduct deployed at 05/15/98 17:02:03

Sales deployed at 05/15/98 17:02:01

Sales

PDF Products deployed at 05/15/98 17:01:59

Products

ed at 05/15/98 17:01:54 Marketing PDF Pricing Pricing deployed at 05/15/98 17:01:57

Marketing Inbox Subscriptions All Reports

WEB-TO-HOST ACCESS TECHNOLOGIES

Options

Help

Logout

Options

Search

New Documents

Inbox Documents

Personal Documents

Corporate Documents

Welcome

Luis Hacker Manager Manager V2 Demo Luis Hacker V2 Demo Luis Hacker Manager Manager Manager Manager

From

Jun 1713:21:00 1998 Jun 1712:12:00 1998 Jun 1712:12:00 1998

Jun 1716:12:00 1998

Jun 23 14:01:00 1998 Jun 23 14:01:00 1998

Jul 23 17:43:00 1998 Jun 15 16:46:00 1998 Jun 25 09:13:00 1998

Jul 23 16:27:00 1998

Jul 23 19:46:00 1998

Date

Exhibit 10-13. BusinessObjects WebIntelligence.

Catalog 4

Contacts by State Category by Year

Sales Revenue Report Product Line Company Addresses by Type

Sentry - Num of Responses by Title Extranet audit report Insurance

Companies by Sector Sentry - Systems Installed By State

Name

11 Available documents. This list was refreshed on Jul 23 19:46:57 1998

13 K 21 K

24 K 17 K 12 K 15 K 49 K 16 K 17 K 639 K 487 K

Size

Web-to-Host Connectivity Tools in Information Systems

131

132

Greenville

Durham

Store

Item

$7,034 $6,405 $5,901 $4,424 $6,457 $3,993 $6,465 $6,392 $7,875

Drill Across

$6.221 $6,930 $2.093 $3,901 $4,682 $5,003 $7,172 Drill Up

(TW-LW) Profit Variance

32% $582.22 35% % $352.70 $2.093 $346.33 82% ($644.08) $182.84 25% $554.35 41% 39% $1,097.54 32% $18.51 Geography $18.23 Time Day Day of Week $70000 23% Last Month 30% $30000 Last Week 36% $0000 Last Year 35% $81222 Month to Date 32% ($41111 Week 31% $30000 Month 31% $71111 Quarter 29% ($1,2000 Season Year

to Total Market

Exhibit 10-14. MicroStrategy DSS Web.

Floral Dress Knit Dress Formal Dress Print Blouses Pe Show Totals Outline Mode Car Show Thresh Shirts Tur Drill Slacks Show Details Football No Col Restore Dresses Plaid Blouse Item Properties... Knit Dress Plaid Blouse Blouses Silk Blouse Camisole Blouse Football NFL Football Cowboys Jersey Kicking Tee

Dresses

Class

Sales ($)

Measures Merchandise Contribution

WEB-TO-HOST ACCESS TECHNOLOGIES

Web-to-Host Connectivity Tools in Information Systems

PRESENTATION

INTERNET

APPLICATION

Web Server Web Basis

R/3 Internet applications SAPls BAPSs

DATABASE

Exhibit 10-15. SAP Web-based infrastructure.

WEB TO ERP Example: SAP R/3 System (www.sap.com). The SAP R/3 application suite includes Internet application components that enable linking the R/3 System to the Internet. These components enable SAP users to use the R/3 System business functions via a Web browser. SAP R/3 Internet applications can be used as they are, or as a basis for creating new ones. SAP R/3 architecture is based on a three-tier client/server structure, with distinct layers for presentation, application, and database (see Exhibit 10-15).

WEB-TO-HOST MIDDLEWARE AND RAD DEVELOPMENT TOOLS Efficient access to legacy data is important from an application developer’s perspective as well. The development of new c/s applications that will exchange data with existing legacy systems requires a type of middleware that overcomes the differences in data formats. Different data access middleware products exist and they are specific to a single platform; for example, RMS files on OpenVMS machines, IBM mainframes, or different UNIX machines. Two examples are given. Example: ISG Navigator (www.isg.co.il). ISG Navigator is a data access middleware tool that provides an efficient data exchange between Windows platform and several host platforms such as OpenVMS for Digital Alpha and VAX, Digital UNIX, HP-UX, Sun Solaris, and IBM AIX. ISG Navigator (Exhibit 10-16) enables access to non-relational data in almost the same 133

WEB-TO-HOST ACCESS TECHNOLOGIES

Tier 1: The Web

Tier 2: Application Server

Tier 2: Data Server

Browser Clients

Web Server Business Logic

Secure, available databases

NT Server 4.0

Open M5 Cluster

RMS Rdb

IIS 3.0 Active Server Pages ADO

Oracle

OLEDB Sybase

SQL data sources

ODBC

ISG Navigator Client

others

ISG Navigator Server

Exhibit 10-16. ISG Navigator.

way that relational data is accessed. More importantly, application developers can build new Internet-based applications that will use data from legacy systems by using data integration standards such as OLE DB, ADO, COM, DCOM, RDMS, CORBA, etc. Example: ClientBuilder Enterprise (www.clientsoft.com). ClientSoft ClientBuilder Enterprise and other solutions provide the following important capabilities in the development of Web-enabled c/s applications and their integration with legacy data:

• data integration between desktop Windows applications and legacy data from IBM S/390 and AS/400 machines • developing GUI interface to existing host-based legacy applications • ODBC support to relational databases • access to applications residing on IBM systems through the use of wireless communications technologies • access to IBM host machines through the use of Web technologies within the electronic commerce systems (see Exhibit 10-17). While middleware products serve as a data gateway between legacy systems and Windows-based c/s and desktop applications, Web-based application development products support building Web-enabled c/s applications. Microsoft Visual InterDev (www.microsoft.com) is a rapid application development tool for building dynamic Internet and intranet applications 134

Web-to-Host Connectivity Tools in Information Systems

Exhibit 10-17. ClientSoft.

based on ASP features of Microsoft Internet Information Server. It is available as a stand-alone product or as a part of Microsoft’s Visual Studio integrated application development suite. Visual InterDev provides Web-based access to databases supporting ODBC standard (see Exhibit 10-18). In addition to specific Web development tools, most contemporary standard rapid application development tools provide features for developing Web-enabled applications. Exhibit 10-19 illustrates such features supported by Borland C++ Builder (www.inprise.com). CONCLUSIONS This chapter presented a framework for an effective integration of Web-tohost connectivity and development tools in information systems. This issue was considered from both end user and developer perspectives. This means that an emphasis is put on how to improve data access and data exchange, no matter where that data comes from: standard legacy data, e-mail or fax message, document, business model, report, ERP module, etc. The IS subsystems in which these tools can be used were identified, and some examples of software packages that can be found on the market were presented. References • www.simware.com • www.gartner.com • www.wrq.com • www.nsainc.com • www.mail2web.com • www.tpc.int • www.microsoft.com • www.altavista.software.digital.com • www.keyfile.com • www.filenet.com • www.sap.com • www.vanguardsw.com • www.isg.co.il • www.cognos.com • www.businessobjects.com • www.strategy.com • www.clientsoft.com • www.microsoft.com

135

Exhibit 10-18. Microsoft Visual InterDev.

WEB-TO-HOST ACCESS TECHNOLOGIES

136

Win 3.1 Samples

Exhibit 10-19. Borland C++ Builder: Internet component bar.

Standard Additional Win 32 System Internet Data Access Data Controls Decision Cube Q Report Dialogs

ActiveX

Web-to-Host Connectivity Tools in Information Systems

137

Chapter 11

Survival of the Fittest: The Evolution to Thin-Client Intranets Jan Murphy

CORPORATIONS

ARE CONSTANTLY GENERATING INFORMATION , AND

changing information, to stay current. They have to keep up with their customers and their competition, while keeping employees informed and up-to-date. It is because of this fast pace and the need to remain current that intranets, which are corporate internets, have become so popular. Intranets are a dynamic way to keep up with changing corporate information while keeping people in the corporation informed. The popularity of intranets focuses on their ease-of-use, ease-of-implementation, and central server maintenance — it is a cost effective way to keep people informed. Intranets are created and centrally maintained by the corporate IS department using TCP/IP protocols, a common browser interface (HTML and HTTP), and a Web server (see Exhibit 11-1). Corporations are turning more and more to Web technology to solve their information problems and give access to business-critical legacy data — data that companies have invested millions of dollars to develop and maintain. This chapter explores why intranets have become popular, the benefits of intranets over older technologies, the advantages and concerns of implementing intranet technologies, and the move toward Web-to-host access using thin-client solutions. THE INTERNET-INTRANET CONNECTION Intranets depend on the physical connections and interoperability of the Internet, which has been an established method of communication for more than a decade. Estimates for the number of current Internet users conservatively start at ten million active users, although the number of users with Internet access 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

139

WEB-TO-HOST ACCESS TECHNOLOGIES

Exhibit 11-1.

Intranet maintained by IS department.

probably exceeds twenty million. A common statement describing the growth of the Internet is that it has doubled in size every year since the mid1980s. What began as a Department of Defense research project in 1969 has become the communications medium of choice in the 1990s. Part of this explosive growth centers on the open standards and protocols that created the Internet — the set of guidelines that everyone follows concerning network physical layers, TCP/IP protocols used for connections, and the applications used to connect to the Internet. Another factor involves allowing corporate access to the Internet, which was originally limited to government, educational, and scientific groups. Without a doubt, the change that truly pushed corporations into using the Internet was the phenomenon of the World Wide Web. The World Wide Web began as a research project at CERN (Conseil European pour la Recherche Nucleaire) in 1989 as a means for scientists to collaborate using the Internet. Two important products that have brought the World Wide Web into focus are: the release of NCSA’s (National Center for Supercomputing Applications) Mosaic Web browser in 1992, and the release of Netscape’s Navigator commercial Web browser in 1994. The Changing Corporate Environment: Why Web Technology Is Becoming Key to Client/Server Environments The move in most corporate environments away from central IS management and a homogeneous computing environment started when client/ server 140

Survival of the Fittest: The Evolution to Thin-Client Intranets

Operating System Upgrade

New Applications Exhibit 11-2.

Hardware Upgrade Distributed computing environment.

technology began to be implemented on a wide scale. The goal of client/server technology is a distributed computing environment, which it has accomplished for the most part (see Exhibit 11-2). However, implementing and maintaining distributed computing environments has given IS departments a corporate-sized migraine. • Most upgrades in a client/server environment have to be implemented not only on the servers, but on each client workstation. This causes the IS manager to upgrade many workstations, instead of upgrading a central point with automatic upgrades to each client workstation. In a corporation of even a few hundred users, the upgrade can take weeks. • The very nature of a distributed environment causes the user interface to change with each upgrade. This means that training requires specialized planning because there is no common user interface. It also means that IS departments cannot immediately upgrade to new features because the training is so time-consuming and costly. • Proprietary software, which is the short definition of legacy host data and applications, does not communicate easily among different hardware platforms. More and more corporate users need access to legacy hosts, but these applications are difficult to use — there is no common interface and no easy way for client workstations to connect directly to the different types of hosts. • Expensive hardware upgrades cause corporations to constantly improve and enhance their client workstations and servers — corporate assets that require major capital expenses each year just to stay current. Aside from the administration and maintenance issues, implementation of a distributed computing environment using client/server technology consistently takes longer than expected. By some estimates, only 18 percent 141

WEB-TO-HOST ACCESS TECHNOLOGIES of conversions to client/server technology happen on time and within budget. Intranet Trends: Client/Server/Web Connections There are two types of client/server/Web implementations: thick client and thin client. Thick-client implementations are the familiar client/ server models: server hardware and software upgrades and multiple user interfaces. Thin-client implementations, using languages such as Java, are platform independent: • Platform independence means that hardware and software becomes less important — it is zero desktop maintenance. IS departments and corporations can take advantage of what they already have, instead of upgrading to more expensive workstations and software at each client workstation. Corporations can also take advantage of the new network computer workstations that are a fraction of the cost of most client workstations. This allows capital expenses to drop because the latest-hottest-fastest computer is not needed to provide access. • Platform independence means every user sees the same interface, which reduces training costs and provides a common knowledge base for users. • Platform independence means that information is updated in one place only — the Web server — and reaches all users at the same time. Instant upgrades provide corporations with a powerful way to inform their user community of changes that they need to do their jobs well. A central update point also ensures version control across the corporation, instead of the IS department maintaining several versions on different servers. Intranets and Distributed Computing Intranets provide cost-effective, distributed computing that is being pulled along by enormous momentum and corporate need. For example, 89 percent of large companies and 54 percent of medium-size companies already have an intranet or will have one within 12 months, according to International Data Corporation (IDC) (see Exhibit 11-3). Half of the companies (52 percent) that plan to migrate to intranets in the next year expect to leverage their intranet to deploy custom, enterprisewide applications, such as database or transaction processing. Intranets and Web Browsers Web browsers provide an interface to the World Wide Web — a dominant interface for many users. According to IDC, 43 percent of medium to large companies see it as the primary interface for enhancing existing applications. With thin-client workstation solutions, there is nothing for IS 142

Survival of the Fittest: The Evolution to Thin-Client Intranets No Plans to Implement 7%

Already Implemented 50%

Exhibit 11-3.

Beyond 1 Year 4%

In 1 Year 19%

In 6 Months 20%

Intranet deployment — projected growth.

departments or users to maintain on their client workstations. The IS department no longer needs to support multiple interfaces because the Web browser is the only common interface. Picture the person running Windows 95 on a PC, the person on a Macintosh, and the person running UNIX on a workstation with the same interface regardless of their hardware platforms and operating-systems software. Intranets and Web Servers Client/server technology began with the growth of server technology. Today, UNIX servers make up the majority of corporate client/server environments. In the near future, NT 4.0 servers are expected to surpass unit sales of UNIX servers and continue to grow in popularity. (See Exhibit 11-4.) Intranets and Legacy Data There is an obvious need to keep everyone in the corporation informed and connected. For example, connectivity products that promote access to legacy applications and data help corporations maintain access to their information without shifting important data to other platforms. The importance of legacy applications and data is supported by the growth of mainframe sales, which have increased 33 percent each year for the past five years. If mainframe sales alone are not enough to show how important legacy data is for corporations, what about the billions of dollars spent to solve the Year 2000 problem? If mainframe data were indeed no longer relevant, why have corporations spent billions of dollars on saving that data for the twenty-first century? INTRANET VALUES AND CONCERNS As with any new technology, there are advantages and disadvantages to corporate intranets. According to a poll conducted by Network World and 143

WEB-TO-HOST ACCESS TECHNOLOGIES

4,500 4,000 3,500 3,000 2,500 2,000 1,500 1,000 500 0 1994

Uni 1995 1996 1997 1998

(Units are in 1000s)

Exhibit 11-4.

Windows NT server projected growth (1994–1998).

International Data Corporation, there are three top advantages and disadvantages. Top Three Values Ease of Use. Ease of use was cited as the top advantage to deployment of client/server and Web technology (79 percent). Users are already familiar with Web browsers and how they work — they do not have to learn new software to connect to corporate information. From an IS perspective, there is only one place to update users with current information — the Web server. One change reaches all users simultaneously, which gives IS departments easy version control. Ease of Availability. This was the next most-cited advantage (69 percent). This includes remote access to corporations for employees who are on the road. Sales personnel can keep up with changes in corporate pricing at the moment it changes. It also allows for scalability in user concurrencies, accommodating a fluctuating number of users at any one time. Ease of Implementation. This was ranked as the third-biggest advantage (65 percent). Most corporations already have intranet technology. The shift toward client/server computing was already taking place in most organizations, along with implementation of Internet standards. In most cases, users already have everything they need to access information via a Web server — this is zero desktop maintenance for the IS department.

144

Survival of the Fittest: The Evolution to Thin-Client Intranets Top Three Concerns Security. Forty-two percent of respondents cited security as the top con-

cern in implementing an intranet. Security is always an issue with access to corporate information. Many of the security issues are addressed already in corporations, because they involve only those users within the corporation that are already allowed access to information. An exception to this is when someone outside the corporate umbrella, such as a salesperson on the road, needs to get information. In this case, a firewall is required to prevent unauthorized access. In many corporations, firewalls are at least partially implemented already as part of normal security measures for authorized users. Lack of Bandwidth. Thirty-three percent of respondents cited lack of bandwidth as the most important concern of implementing an intranet. Slowed response time can be a problem that hampers access to information. This problem can happen when an already stretched corporate LAN is tasked with the additional work of allowing access to corporate Web servers, as well as host applications. Lack of Applications. Thirty-two percent of respondents cited lack of applications as the most important concern of implementing an intranet. Web servers can talk with client workstations, and Web servers can talk with the Internet. What is needed are applications that work with clients and hosts to get them connected easily, instead of creating custom (and costly) applications.

INTRANETS IN THE FUTURE: WEB-TO-HOST ACCESS Ninety-three percent of respondents to a recent Communications Week reader poll indicated that they would consider using a Web browser to access their mainframe data. This type of access is called Web-to-host access, and comes in three phases: publication of static information, Web access to legacy hosts, and new browser/Web applications. Phase One: Publication of Static Information Static information includes personnel policies and procedures, corporate phone directories, product specifications, and financial reports — information that is typically circulated within the corporation in printed form. Access to this type of information is generally converted from the printed format to HTML format and resides on the Web server rather than a host. It is information that was updated periodically, but because of HTML, it can now be updated dynamically.

145

WEB-TO-HOST ACCESS TECHNOLOGIES Phase Two: Web Access to Legacy Hosts Web access to legacy hosts includes client addresses and product inventory, location of OEM or VAR partners, current prices on company products, and any other information that supports simple searches on host databases. It also includes enterprisewide data access and transaction processing. Access to legacy hosts via Web servers is generally provided by the makers of the database software and independent software vendors. Web access to legacy hosts also includes running host applications to change and update database information. When Web servers act as connections between clients and hosts, the Web server must run protocols that are native to the connecting host, such as tn3270 or 5250. In effect, the Web server looks like a legacy terminal to the host and a Web server to the user. Solutions to this connection problem are available today, using the emulation technology that has been employed for decades to solve the very problem of client-to-host connectivity. Phase Three: New Browser/Web Applications Browser/Web applications allow users the same access defined in phases one and two above, but add something to it. For example, access to a tn3270 host, without enhancements to the navigation, does not provide added value. An interface that lets IS extend access to tn3270 connection using the standard “green screen” and a GUI interface is of value to a corporation beyond just connecting to the host. The unifying mission of most new browser/Web applications cannot be overstated: • to reduce software costs significantly, because browser software is cheap • to reduce the costs of hardware significantly, because client workstations do not need additional memory or disk space — nothing is installed locally • to reduce training time and costs, because the browser is the point of access for all types of Web-to-host interactions • to reduce maintenance for IS because changes are made to one place — the Web server What to Keep an Eye On in the Near Future The combination of Web technology and client/server technology is where the future is headed, and the future is today. Much of the groundwork has already been implemented with client/server technology, distributed computing, Web access, and use of familiar interface. The challenges facing complete integration of intranets into corporate environments for the near and short term can be grouped into two categories: people and technology. 146

Survival of the Fittest: The Evolution to Thin-Client Intranets People Challenges Defining the type of users in a corporate intranet and their needs is critical to the success of its implementation. Through various user surveys independently conducted by Persoft, Sun Microsystems, and IBM, the average Fortune 1000 corporation includes four types of workers: • Data-entry users (50 percent of all users) update client databases, fulfill orders, or access client records as a customer representative. This type of person is keyboard intensive, and generally accesses only a single host for their daily work. • Information-driven users (10 percent of all users) need current information fast, and it needs to be accurate. This type of user is an executive or is in sales or marketing, may be on the road or on the phone regularly, and wants information quickly. This type of user also may access one or two hosts for information, and is considered a software user who does not want to waste time shifting among multiple software packages. • Office users (30 percent of all users) perform light processing, do ad hoc queries on corporate databases, and use applications such as spreadsheets and desktop publishing. This type of user is an administrative assistant, financial analyst, or marketing researcher — a strong Windows application user, for example. Access to hosts is not important, except when host access is needed for electronic mail. • Power users (10 percent of all users) are involved in product development, engineering, quality assurance, and manufacturing. This type of person uses intensive processing, many applications, and is a software guru. In examining the needs of the software community, the network manager will be assessing Web-to-host solutions that can best support the variety of users. Implementation is easier when users see change as something that benefits them directly in their work. Technology Challenges Being aware of technological pitfalls that can affect intranet implementation is the best defense. Most of these challenges are new because of the three-way communication of Web browser to Web server to host. They can be grouped into the following three categories: • Browsers and hosts do not speak the same language, so software is needed between Web clients and hosts, which is where the Web server acts as translator. Server-to-host access is already part of most emulation software currently on the market, so going the extra measure to provide assured access is within reach. Additional solutions include HTML protocol converters that reside on the host. 147

WEB-TO-HOST ACCESS TECHNOLOGIES • Platform independence makes keyboard support difficult for users that require data-entry type access. This type of support allows users to press keyboard keys to navigate within host-based applications. This type of access is completely opposite to the hypertext links and point-and-click navigation provided with current Web browsers. One solution is to provide fat clients (with minimal installation on client workstations) for those users requiring keyboard support. • Web-to-host synchronization can be a problem when bandwidth use reduces response time between the client running the Web browser and the Web-to-server connection to the host. The effect is similar to a movie that has been dubbed when the timing gets out of sync: the words start falling behind the motions of the actors in the movie, and the movements and sound get more out of sync as the timing error continues. SUMMARY Corporate intranets provide a link to the client/server technology that is already in place in many organizations. The advantages of client/server/ Web connections are lowered hardware and software costs, central management, dynamic disbursement of corporate information, and a common user interface using Web browsers. Intranets today already provide access to static corporate information (i.e., personnel policies and employee directories) and Web-to-host access. The new challenge for intranets is to provide new Web/browser applications that support and enhance corporate access to legacy applications and data. Web-to-host access to data and applications will dramatically increase as vendor solutions that include new Web/browser applications continue to mature.

148

Chapter 12

tn3270 and tn5250 Internet Standards Ed Bailey

WHY IS ACCESS TO SYSTEM/390 AND AS/400 TERMINAL APPLICATIONS using the Internet so important? There are three basic reasons. 1. These terminal applications represent a large percentage of the data and logic of a typical enterprise. 2. There is a huge installed base of users who are currently accessing these applications productively. 3. New devices and end systems are being enabled with technology to access these applications. ENTERPRISE DATA AND LOGIC For larger enterprises, 70 percent or more of their mission-critical data resides on mainframes. While System/390 and AS/400 terminal applications are typically referred to as legacy applications, they collectively represent a vast majority of the business infrastructure upon which our economy rests today. And with a solid foundation of business logic that represents a history of investment, users of these applications rely heavily on their ability to access them to perform daily business transactions. USER PRODUCTIVITY AND CONFIDENCE Most of these terminal applications emerged in the late 1970s and early 1980s during the evolution from batch to online processing. Brought about by the introduction of the computer terminal and System Network Architecture (SNA), online processing gave rise to more direct access to enter, view, and alter information by the end user (see Exhibit 12-1). This empowered the individual and allowed productivity to soar. The ongoing reliability and availability of these terminal-oriented applications fostered confidence in the Information Technology (IT) professional and the end user to commit to completing ever-increasing volumes of transactions interactively. 149

WEB-TO-HOST ACCESS TECHNOLOGIES

Exhibit 12-1.

Exhibit 12-2.

Terminal-oriented applications.

PC emulation of terminal functions.

NEWER PLATFORMS AND DEVICES Since their introduction, personal computers have been used to emulate the terminal functions without requiring change to the host application. This emulation, along with new personal computing paradigms for downsized solutions and client/server distributed platforms, has not displaced System/390 and AS/400 terminal applications. Rather, the technology that these approaches of the 1990s represented has propelled end user productivity to new heights. Greater end user mobility has also contributed to this technology, which enables the use of much smaller yet powerful devices such as laptops and PDAs (see Exhibit 12-2). 150

tn3270 and tn5250 Internet Standards IBM Mainframe

IBM AS/400TM

SNA Network

SNA Network

Web Server, TN3270 Server

Web Server, TN5250 Server

Public Internet

PCs with Web Browser

Exhibit 12-3.

Internet access to SNA applications.

With more power at their fingertips, the demand by users for access to System/390 and AS/400 terminal applications remains high as even newer and more innovative approaches are developed to manipulate and present the information that these applications maintain. The most recent contributor to this demand has been the increased number of users served by the advancement of the Internet and World Wide Web. Viewed as the open global information highway, the Internet is expected to provide worldwide access between the information provider and the consumer. Electronic commerce (E-commerce) has quickly become the model for conducting business involving the Internet this millennium. It then stands to reason that if one intends to participate in E-commerce, then System/390 and AS/400 terminal applications must be accessible to end users using the Internet. (See Exhibit 12-3.) Basic to the Internet is use of Transmission Control Protocol/Internet Protocol (TCP/IP). Standards have been developed to enable access to SNA terminal applications using TCP/IP. These standards are tn3270 and tn5250. Client and server implementations of tn3270 and tn5250 provide access without requiring change to the host application. (See Exhibit 12-4.) These standards are actively evolving to adopt additional Internet technologies associated with Web browsers and programming. The remainder of this chapter addresses the tn3270 and tn5250 standards for using the Internet to access System/390 and AS/400 terminal applications. 151

152 Exhibit 12-5. tn3270 and tn5250 server.

Exhibit 12-4. Internet Protocol to access SNA applications.

WEB-TO-HOST ACCESS TECHNOLOGIES

tn3270 and tn5250 Internet Standards HOW DOES STANDARDIZATION HELP? The Internet consists of processors that are interconnected via transmission links. Some of the processors are designed to do a special task such as establish a path or route the information along to the next destination, while other processors provide services to end users such as security or information retrieval. Typically, the processor that the end user operates directly is called the client, and the processor that contains the application is called the server. To access a particular application, an end-user request may pass from the client through multiple processors before reaching the correct server. The manner in which these processors communicate is through the use of protocols. Left to chance, it would be very unlikely that any of the independent implementations of hardware and software would operate well — if at all — with other implementations. This creates a multitude of business and technical challenges for IT professionals and their end users. Therefore, consumers expect developers of Internet products and services to follow specifications, known as standards, produced by the Internet Engineering Task Force (IETF). The IETF is the organization that facilitates open participation in producing Internet standards and promotes interoperability among various Internet components from different sources. The benefit of greater interoperability among particular implementations is higher confidence in their use and the use of the Internet overall. More information on the IETF is available at http://www.ietf.org. PROTOCOLS A closer examination of the various components of tn3270 and tn5250 allows one to better understand the benefits of standardization. One begins with the protocol. Simply stated, the protocol is the manner in which two components establish and maintain communications. As observed in Exhibit 12-4, there are two network protocols involved to allow end users to access SNA applications via the Internet: TCP/IP and SNA (Systems Network Architecture). Any enterprise with 3270 or 5250 terminal applications will have SNA protocol. Also, any enterprise with access to the Internet will have TCP/IP. Enabling users to be connected to the Internet using TCP/IP and have access to SNA applications requires two key components, referred to as servers and clients (Exhibit 12-4). Servers A server has the important role of initiating, managing, and terminating the SNA flows required by the OS/390 and AS/400 applications business logic. This is depicted as “A” in Exhibit 12-5. A server can include the entire protocol stack or use the programming interface provided by an existing stack. The SNA resources assigned to the server are used to support 153

Exhibit 12-6. tn3270 and tn5250 client.

WEB-TO-HOST ACCESS TECHNOLOGIES

154

tn3270 and tn5250 Internet Standards requests from the end user. A server may reside on the same processor as the application, or on a different processor. The server passes the SNA data stream received from the terminal application to the end user by supporting the TCP/IP flows to and from the client. Requests and responses flow to and from the user on the TCP/IP connection maintained by “B” in Exhibit 12-5. A server may provide the TCP/IP stack or rely on the use the programming interface of an existing stack. The role of “C” is to pass the data stream between “A” and “B.” Early implementations of tn3270 and tn5250 servers conveyed only the data stream and very little information to the client about the SNA connection. The latest specifications include many more options for passing additional information to the client about the SNA connection and resources. Clients The client maintains the graphical end-user interface (GUI) and connection to the server (see Exhibit 12-6). Component “D” is responsible for initiating, maintaining, and terminating the connection to the server using TCP/IP. Just like the server, it can include the TCP/IP stack or use the programming interface of an existing TCP/IP stack. Component “E” sends and receives the data stream with the SNA terminal application and provides the GUI to the end user. The latest specifications include more options that enable the client to provide the user with many more choices for presentation of the information. Because multiple client and server implementations exist in the market and the client implementation can be obtained from a different source than the source for the server implementation, one can readily see how interoperability could be an issue without the benefit of standards. Keep in mind that standards evolve and do not always address every unique circumstance. Therefore, they allow for options that are left to the discretion of the implementers. Although a tn3270 or tn5350 client or server makes a claim of support for the standard, it is the set of options that should be examined closely against the requirements to determine the best solution for a business. Options for supporting such technologies as security, management, and programming should receive particular attention. INTEROPERABILITY The IETF charters working groups to address particular Internet problems or requirements. The tn3270(E) Enhancements Workgroup was such a workgroup chartered under the Applications Division. This workgroup has produced a number of specifications for enhancing tn3270 and tn5250. In support of the implementation of these specifications, the workgroup has conducted a number of interoperability tests. 155

WEB-TO-HOST ACCESS TECHNOLOGIES Basic interoperability testing focused on: • • • •

how well the server connected with the SNA application how well the server connected with the client how well the client connected with the server how well the client displayed the information

Results from the interoperability tests have been the consistent interpretation of the specifications, the increase in the number of new clients and servers, and the solidification of the protocol on which to base additional enhancements. Enhancements As end users access System/390 or AS/400 SNA terminal applications from the Internet, certain characteristics that existed in their prior access are expected. The workgroup has defined specifications to support these characteristics that include: 1. Security (encryption, authentication, authorization). This specification addresses the application level security based on the Transport Layer Security (TLS) standard and Secure Sockets Layer (SSL). 2. Management (configuration, response time monitoring). Two MIB specifications here address the configuration and response time monitoring for service-level management. 3. Performance (service location, session balancing, caching). This specification addresses the use of the Service Location Protocol (SLP) standard to identify services dynamically and learn their current workload factor. Current efforts are under way by a number of vendors to implement these new specifications. These capabilities will enable IT professionals to deliver consistent levels of service to their end users when using the Internet. Programming With the growing popularity of E-commerce, independent software vendors (ISVs) want to deploy more Internet-ready applications. Most ISVs traditionally rely on the ability to build their services on top of clients and servers. Users want to integrate information from a variety of sources and formats with the data available from SNA terminal applications. Satisfying the need of the ISV and end user in this problem space requires new programming capabilities extensible to the Internet user. This leads to the use of object classes, object interfaces, and transform services. The support for Hypertext Markup Language (HTML), Java, and XML in browsers requires new programming interfaces that provide programmatic interaction with the SNA terminal application. 156

tn3270 and tn5250 Internet Standards SUMMARY The use of the Internet to access SNA terminal applications is considered to be rejuvenation as it opens up new markets and expands the reach of end users. tn3270 and tn5250 specifications are designed to support the needs of these applications. Interoperability and standardization have established confidence in their use. Migration to these technologies by the enterprise results in: • • • •

no change to the terminal application reduced SNA networking complexities consistent user interface and tools E-commerce enabling

When selecting an implementation of a tn3270 or tn5250 client or server, always request interoperability information for the implementation from the provider. This information should state how well this implementation operates with similar implementations from other sources. An implementation that has not been well-tested with other implementations may be lacking in capability and leave requirements unsatisfied after installation. If the provider is unwilling to produce such information, one should ask oneself the question, “Do I really want my mission-critical applications to depend on this implementation?” INTERNET INTEGRATION The tn3270 and tn5250 standards established by the IETF paved the way for the next generation of technologies for Internet integration of the System/390 and AS/400 SNA terminal applications. Comparing the role of the protocols to that of a typical package delivery service, the emphasis is on preservation of the package or data stream (sometimes referred to as the payload) from end to end. This gives the most consistency in behavior for presentation of information to the end user when compared to the original terminal or emulator. (See Exhibit 12-7.) When the application creates the data stream (1), it remains intact and unchanged as it travels to GUI (6). Although use of the Internet is made to carry the data stream to the end user, this does not support integration of the information with other Internet applications. The Web browser has introduced a new behavior that can enhance the presentation of the information to the end user. The use of a browser may require transformation of the data stream into another format — HTML and XML technologies use transformations. Java, on the other hand, does not require a transformation of the data stream. As an applet, it is designed to correctly process the original data stream. Typically, the transform occurs at Point 3 in the flow in Exhibit 12-7. However, some designs may actually not perform the transform until Point 6. 157

Exhibit 12-7. Data stream flow.

WEB-TO-HOST ACCESS TECHNOLOGIES

158

tn3270 and tn5250 Internet Standards One can see that careful thought should be given to where the transform occurs. Performance and function can be significantly affected. The use of objects to assist in processing the data stream is advancing the use of transforms. This is the momentum behind such efforts as the Open Host Interface Objects (OHIO) specification to establish an industry standard. Placing object interfaces into Point 3 or 6 greatly enhances the capabilities of vendors and users to integrate the information from SNA terminal applications with other Web and Internet bases while maintaining function and performance. All the excitement of E-commerce has brought a number of new players to the market, providing SNA terminal application integration into the Internet. How consistent these implementers are in developing and using transforms and objects can impact E-commerce deployment within an enterprise. One should know where and how the transform is achieved before committing one’s business to a particular implementation. LOOKING FORWARD Many of today’s business processes (e.g., inventory, finance, claims, manufacturing, shipping) lack integration with the Internet due to a previous inability to offer services to end users that they needed and were accustomed to using. Slow progress is partly attributed to insufficient security and manageability. Although still maturing, recent enhancements in the market have produced better solutions that enable enterprises to speed up Internet integration of their host terminal applications and enter into E-commerce. Note System 390, CS390, and AS400 are trademarks of International Business Machines Corporation.

159

Chapter 13

Publishing Host Data Using 3270-to-HTML Conversion Carlson Colomb

EXTENDING HOST DATA

THE INTERNET

AGE HAS TRANSFORMED THE FACE OF BUSINESS .

THE

explosion of the Internet has underlined the public’s demand for 24/7 access to information. And it is this same technology and demand for information that now drives business-to-business transactions around the globe. With an estimated 70 percent of corporate data residing on legacy host systems, it only makes sense to leverage this valuable source of information to fulfill this demand. Now, corporations can use 3270-to-HTML conversion products to extend host-based information to their employees, partners, suppliers, and customers. By bringing host data right to users’ Web browsers, corporations are realizing tremendous savings through efficiencies and new revenue opportunities. In fact, utilizing existing host applications and extending the reach of those applications provides an extremely high return on IS investments. By leveraging legacy systems, enterprises benefit from a new application portfolio without the high cost needed to design, develop, test, and roll out new applications. In addition, 3270-to-HTML conversion solutions can be implemented much faster than new host application development or rewrite. Web-enabling SNA applications via 3270-to-HTML conversion is uncomplicated, flexible, highly cost-effective, and proven. Eicon’s Aviva Web-to-Host Server, Novell’s HostPublisher, and Attachmate’s Host Publishing System are leading examples of this technology that permit SNA applications running on a mainframe to be readily accessed from within a standard Web browser. These products can essentially provide two levels of rejuvenation capability for Web-enabled host access, without having to change the original host application. First, they can provide an out-of-the-box, on-the-fly 3270-to-HTML conversion that provides a simple “default” rejuvenation of 161

WEB-TO-HOST ACCESS TECHNOLOGIES

Exhibit 13-1. Eicon’s Aviva Web-to-Host Server.

the dated “green-on-black” 3270 user interface used by most SNA applications, which may be useful for certain intranet users. Second, and where the true strength of 3270-to-HTML conversion lies, is enabling companies to develop completely custom rejuvenation of the “green-screen,” into a more intuitive contemporary Web page interface within a Web browser. The end result is so remarkable and transparent that users are unable to distinguish that the data provided to them in the Web page resides on one or more legacy applications written a decade ago. That is the power of 3270-to-HTML conversion: SNA applications appear as custom and modern Web pages (Exhibit 13-1). FLEXIBLE TO SERVE MANY USES AND USERS Diverse user groups each have differing needs for host data, and the application possibilities for 3270-to-HTML conversion are virtually limitless. 3270-to-HTML conversion is most often implemented for users external to the enterprise or for users who require occasional access to information. It is best suited for providing access to limited, select, and specific host data for an end-user base that is not familiar with navigating host applications and requires only quick transaction-based access to certain host data. Although such users are typically found in E-commerce scenarios (e.g., transacting with customers over the Internet), there are also numerous cases of such user requirements in E-business type scenarios with partners/suppliers, or 162

Publishing Host Data Using 3270-to-HTML Conversion

3270toHTML

SNA or tn 3270 Web Server Interface Web Server

Intranet or the Internet HTML

Web Browser

Exhibit 13-2. 3270-to-HTML conversion.

internal uses such as mobile employees or smaller remote offices. And so, Web browser users can access data center resources across intranets, extranets, and the Internet. Another advantage of 3270-to-HTML conversion is that the end-user desktop does not have to meet any minimum requirements for, say, running Java or ActiveX. All that is required is that the end user have a browser; thus, virtually any operating environment is supported: DOS, 16- or 32-bit Windows, OS/2, UNIX, Linux, and even Mac. This is especially critical for E-commerce and some E-business applications where there is little or no control over the end-user computers. Thus, the customer/user base is not limited to those with a given browser or OS. And equally important in E-commerce and E-business is security. 3270-to-HTML conversion, due to its very nature, supports industry-standard SSL security through the connection between the Web server and the end user’s Web browser. Further security is also realized thanks to the nature of the 3270-to-HTML conversion; since the technology only extracts certain host data and there is no “direct” connection with the host, users cannot access other confidential host data. SIMPLE YET POWERFUL ARCHITECTURE 3270-to-HTML conversion is a gateway function usually performed on a Web server (Exhibit 13-2). After the user submits data in a form on the Web browser, it is delivered to the gateway by a Web server in Internet-standard HyperText Markup Language (HTML). The gateway converts this HTML request into a 3270 data stream, over SNA or tn3270, to the host application, subject to the necessary authentication and security measures. The 163

WEB-TO-HOST ACCESS TECHNOLOGIES host application responds to the request by automatically navigating to one or more 3270 screens that contain the desired data. This data is extracted and communicated to the gateway, which formats it to HTML as desired and then passes it to the Web server for delivery to the browser user. Of course, 3270-to-HTML conversion implementation can be either unidirectional (read-only) or bidirectional (read and write) so that information that is accessed can be updated from the Web browser interface. Web pages can be custom designed to include data from one or more data sources. 3270-to-HTML conversion offers a variety of data integration options. Thus, it can also integrate nearly any back-end data source without the need for application rewrite or new application development. Instead of modifying each data system for Web access, one can install a 3270-to-HTML conversion product that also allows interfaces to 5250, VT, and ODBC data access. The integration of the back-end systems is performed on the 3270-to-HTML conversion server, resulting in HTML being delivered to the Web server where the Web page is customized. ADVANTAGES OF 3270-TO-HTML CONVERSION The advantages of 3270-to-HTML conversion includes • host applications residing on a mainframe are Web-enabled • AutoGUI tools and scripting permit custom rejuvenation of the user interface without changing the host application • the ability to consolidate data from multiple hosts, multiple host applications, and other data sources within a single Web page • no client software required at the user workstation other than a standard Web browser (zero deployment) • browser and client operating system independence via pure HTML output (PCs, Macs, UNIX workstations, Windows CE, etc.) • works with standard Web server-based security and encryption schemes, such as SSL; permits persistent user sessions and user authentication; further security because the user never logs “directly” on to the host • configuration management centralized on the Web server and remotely accessible by administrator • reduced cost of ownership due to centralized installation; it is not necessary to update workstations, as they simply use their browsers • no learning curve due to completely familiar data presentation through customizable intuitive Web page interface, resulting in decreased user-training costs • faster time to market through low-cost, simple, and virtually overnight “augmentation” of host applications, eliminating the need for timeconsuming and costly re-writing of host applications

164

Publishing Host Data Using 3270-to-HTML Conversion • extends proven and established data center applications to the Web for E-commerce and E-business • replace existing private multi-protocol networks used to interconnect remote offices with corporate headquarters by Internet-based and cost-effective Web-to-host access 3270-TO-HTML CONVERSION APPLICATION SCENARIOS Web-to-host integration technology can be profitably used to synergistically bring together proven data center applications and new Web-based users in a plethora of different scenarios ranging from purely in-house intranet-specific situations to E-commerce initiatives that straddle the globe. Some examples of high-return-on-investment uses for today’s proven Web-to-host integration technology follow. Online Trust Management Many banks provide a variety of trust management services for some clientele. Often, a trust fund will consist of underlying stocks, bonds, mutual funds, and real estate holdings. Understandably, fund owners require upto-date status checks on the performances of their trust funds. Typically, banks use mainframe applications to manage these trust funds. Many banks require trust fund clients to either call or visit the bank and talk to a trust fund manager to gain the information they require. This approach is inconvenient for the clients and inefficient, disrupting the trust manager’s schedule and tasks. A more ideal solution is available through 3270-to-HTML conversion, which can be used very effectively to provide trust fund clients with easy, realtime access to trust fund information. It has all the necessary security features to guarantee that only authorized users can gain access to the data, and that all data being conveyed across the Internet is securely encrypted on an end-to-end basis. The user interface seen by the trust fund clients is presented as a contemporary Web page of a “point-and-click” nature. Finally, since the mainframe access is across the Internet, the trust fund clients will only require a standard Internet connection to reach the bank. This access will not require any special software — just a standard Web browser. The result is a secure and easy-to-implement Web-based access to trust fund status that eliminates the need for trust fund holders to regularly call or visit the bank trust fund manager to obtain information on their trust funds. This improves trust fund client satisfaction by providing fast access to required data, and increases savings through better allocation of trust fund management time.

165

WEB-TO-HOST ACCESS TECHNOLOGIES Courier Parcel Tracking Service Thanks, partially, to the Internet facilitating global business, there is a strong and growing demand around the world for freight and expedited package delivery services. Commercial airlines augment their passenger revenues by transporting freight and urgent packages. There are also traditional cargo-carrying van lines (e.g., National Van Lines, Atlas, etc.) and specialized expedited package delivery companies (e.g., FedEx, UPS, etc.). Such companies usually rely on mainframe applications to track freight movement and delivery status. With enormous volumes of freight and packages being delivered to all corners of the globe, around the clock, there is constant demand for up-to-date information on shipment status. In the past, call centers were the only means these companies used to address queries for shipment status. Shippers or customers awaiting freight/packages would phone the call center, quote a parcel number, and then have a representative track the progress of that item using a mainframe application. With today’s popularity of the Internet, 3270-to-HTML conversion provides a more cost-effective means to provide parcel tracking. Customers are able to directly access the requisite information just by entering the parcel number(s) into a specified input field on an easy-to-use Web page incorporating 3270-to-HTML conversion technology. Rather than phoning a call center, customers are able to get all the information they want online, 24/7 across the Web — quickly, securely, and effortlessly — without having to wait patiently “on hold” until “the next available operator” can take the call. Thus, customer satisfaction is increased via self-serve access to delivery data, while freight companies realize significant cost savings by scaling back their call center operations. Government Agencies Publishing Public Information Many local and state governments and their associated agencies maintain large and diverse databases of public domain information on IBM mainframes. For example, a particular State Department maintains its entire library of land zoning, property plot plans, and building layout maps on a central mainframe. This information, which one would expect to find in a “map room” at a local authority, is nonclassified, public domain information that is open to any member of the public. Providing the general public with direct access to such mainframe information, across the Internet via a standard Web browser, eliminates the need to visit or call the local authority. Given that U.S. public libraries now offer free Internet access, providing this type of host information via the Web is a complementary and logical approach. It ensures fast and efficient service, eliminating delays associated with trying to gain this type of data via the telephone, fax, or mail. Providing such data over the Web also satisfies the charter that most states 166

Publishing Host Data Using 3270-to-HTML Conversion have already instituted to make as much of their data Web-accessible, as soon as possible. Governments can thus better serve their public by making public information more readily available. The public no longer needs to be constrained by the limited government “open hours” of operation, and can access information at any time. 3270-to-HTML conversion has provided an inexpensive, easy-to-implement, near-zero maintenance solution that enables the general public access to data to which they are entitled, over the Web, in a user-friendly interface, without the need for either any special software at the client end or any specialized hardware. Web-Enabling Automobile Dealer-to-Manufacturer Communications Automobile manufacturers have chains of dealerships worldwide that sell and service the manufacturer’s automobiles in addition to supplying customers with parts or accessories they might require. These dealerships require constant online access to the manufacturer’s mainframe host systems to look up parts, order parts, order new automobiles, check on delivery schedules, and reconcile financial accounts. Typically, dealers need to purchase IBM-specific communications adapters and emulation software for multiple PCs and then use dial-up connections to realize host access. Some of the larger dealerships might have dumb terminals, 3270 control units, and even expensive leased lines, which are old, unreliable, slow, and very expensive to maintain. 3270-to-HTML conversion PC-to-mainframe access across the Internet will provide these dealerships with the host access they require without the complexity, cost, or unreliability of what they have today. Using 3270-to-HTML conversion, automobile manufacturers need not change host applications in any way. Dealers will require simple PCs with standard Web browsers and local Internet connections through an Internet service provider (ISP). Manufacturer host data can be accessed directly from the dealership user’s Web browser, appearing as a user-friendly Web page. Increased user efficiency and reduced user training time are realized. But even greater benefits result from increased reliability and reduced complexity and maintenance costs of dealer-to-manufacturer communications. Web-Based Access to Host Data for Mobile Salesforce Mobile salespeople in the field require online access to customer accounts, product pricing, and availability data. In many corporations, this data is stored on host systems. Many salespeople rely on printed materials or telephone communications in order to receive such information. However, printed documents can quickly become out of date and thus prevent giving a specific customer the most competitive price. Similarly, product managers or accounts receivable personnel may not be available when the 167

WEB-TO-HOST ACCESS TECHNOLOGIES salesperson calls for information, and cannot function as a “salesforce call center.” Often, salespeople must make numerous sales visits to a given customer in order to deliver price quotes or delivery dates piecemeal. The result is poor salesforce efficiency due to longer sales cycles, increased cost of sales due to increased number of visits, increased risk of competitors stealing business, and lost opportunity costs. 3270-to-HTML conversion allows salespeople to benefit from having direct access to required host information in realtime over the Internet, while at the customer site. Easy-to-use Web page interfaces provided by 3270-to-HTML conversion allow salespeople to access the necessary host data by simply dialing a mobile ISP account (e.g., AT&T Business Internet Services) while at the customer location. In addition, because 3270-to-HTML conversion delivers pure HTML, this Web-to-host access is available through “thin” Web browsers, such as Microsoft’s Pocket Internet Explorer for Windows CE portable computers. With 3270-to-HTML conversion, Web pages can be designed to fit the screen size of the palm-sized or hand-held devices running Windows CE that are popular with mobile salespeople. Armed with direct access to current information, salespeople can react faster to customer questions and arguments and provide firm price quotes and delivery dates with confidence, while on site. A knowledgeable and confident sales representative often wins the business. Similarly, this sales representative knows when to walk away from a potentially money-losing sales agreement. Online Access to Student and Curriculum Information Many academic institutions maintain much of their student information (e.g., grades, courses taken, requirements for graduation) plus their course curriculums on mainframe host computers. Since mainframe access, until now, has required special emulation software (or equipment), academic institutions did not provide students with direct access to the information maintained on the mainframes. Instead, students had to either visit or call an administrative center and talk to a representative to get information about their courses, performance, or academic requirements. Considering the number of students in the average college-level institution, this one-onone type of administrative service is costly, requiring multiple representatives to handle student queries. In addition, in order to attract new students, including foreign students, these institutions need to publicize their curriculums with as much detail as possible. 3270-to-HTML conversion provides a very easy mechanism for existing and prospective students to gain authorized, secure, and monitored access to mainframe-based data. By enabling mainframe access across the Web, existing students can check and print their academic reports online, using their current Web browser. Prospective students from around the 168

Publishing Host Data Using 3270-to-HTML Conversion globe and existing students can also investigate curriculums and course details, across the Web, and even register to attend courses. This allows the academic institution the ability to significantly reduce administrative costs, provide better service to students, and easily extend the target market for the university/college to cover the world. CONCLUSION 3270-to-HTML products are a versatile, secure, and cost-effective means to publish host data to new user groups. They allow corporations to leverage and extend their existing host applications for uses that go far beyond their original design, without changing a line of code. A synergistic relationship results from melding the vast wealth of twentieth century data center resources with twenty-first century Web technologies in order to deliver unprecedented access to information. 3270-to-HTML conversion can effortlessly serve various types of applications and user groups, from lucrative Internet-based E-commerce initiatives, to achieving partner efficiencies via E-business, or even internal users by slashing networking costs and making host information mobile. With 3270-to-HTML conversion solutions currently available and proven — from such notable vendors as Eicon Technology, Novell, and Attachmate — the time has come for corporations to realize the true potential of their data centers.

169

Chapter 14

XML-Based Business-to-Business E-commerce Michael Blank

MOST COMPANIES HAVE ALREADY RECOGNIZED THE BENEFITS OF DOING BUSINESS ELECTRONICALLY. E-commerce takes many forms and includes supply chain integration, procurement, online banking, and shipping and logistics. Solutions such as Enterprise Resource Planning (ERP), Electronic Data Interchange (EDI), and the Web have formed the foundation for Ecommerce today. These applications link groups of departments, divisions, and companies that want to buy, sell, and exchange services and products, and that depend on seamless information access. However, to remain competitive, companies will have to find solutions to extend their electronic trading networks among companies of all sizes. The technological hurdle to overcome is to find ways to access data that may reside in other complex systems, such as legacy databases, ERP, EDI, and the Web. The goal of this chapter is to explore how XML (Extensible Markup Language) technologies allow businesses to rapidly and easily engage in business-to-business (B2B) E-commerce. It explores how companies can achieve application-to-application integration across highly heterogeneous environments by leveraging existing investments in legacy and Webbased products and technologies. COMMERCE COMPONENTS To fuel the growth of electronic trading networks beyond the enterprise, three major sources of information must be unlocked — EDI, ERP, and electronic commerce on the Web. A B2B integration solution must allow these disparate systems to communicate with each other, without requiring changes to the systems themselves. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

171

WEB-TO-HOST ACCESS TECHNOLOGIES EDI EDI is based on a set of computerized forms that automate common business transactions such as package orders, invoices, shipping notices, and requests for proposals. EDI lets companies send and receive purchase orders, sales orders, invoices, and electronic payments. EDI messages consist of agreed-upon data elements that typically appear in commercial business forms: names, addresses, prices, dates, and item numbers. Standardized lists of these data elements comprise forms such as purchase orders, invoice, ship notices, and medical billing forms. Hundreds of these forms have been developed over the past 20 years or so by a committee called X.12 of the American National Standards Institute (ANSI). International EDI standards have been coordinated by a United Nations organization called UN/EDIFACT. EDI documents are essentially flat text files. They must be translated out of and into trading partners’ internal systems, often at great cost. The widespread acceptance of EDI historically has been hampered by the prohibitive development and maintenance costs. Because EDI is a rigid standard, it requires complicated, proprietary translation and integration software. Furthermore, EDI is typically carried over private value-added networks (VANs), which requires expensive hardware as well as a transaction- and volume-based subscriber fees. As such, EDI solutions have been limited to large companies, while excluding any trading partners that may not have the purse to play along. Because EDI is so expensive, cumbersome, and proprietary, Forrester Research estimates that only 2 percent of electronic transactions are done via EDI. The Internet, with its low cost of entry and ease of use, could change all that; EDI over the Internet currently allows organizations to access a wider range of trading partners. Although Internet-based EDI would eliminate the need for proprietary VANs, it does not address the need for costly translation software and integration with enterprise applications. Traditional EDI vendors, such as Sterling Commerce, Harbinger, and GE Information Services, have allowed smaller companies to participate in EDI activities by providing Web-based forms for manual entry of EDI information, which is translated to an EDI format and forwarded to a larger trading partner. Internet-based EDI is still very interactive, and allows very little automation in comparison to direct automated VAN access from one company’s system to another’s. Other forms of Internet-based EDI include sending data through encrypted e-mail. While Internet-based EDI is offered by several vendors, they are not interoperable, again due to the lack of standards. Large trading companies 172

XML-Based Business-to-Business E-commerce have coerced EDI standards to conform to their business processes, making it difficult for smaller companies to compete. With different standards between trading partners, a company might have to support as many EDI implementations as they have trading partners, making it too costly for smaller companies to participate. While the Internet expands the network reach of EDI, there is still a market requirement for seamless information exchange among all trading partners that extend the reach of proprietary EDI networks. As one will see, EDI combined with XML-enabled integration solutions holds the promise of leveling the playing field and achieving a high degree of interoperability. ERP The Enterprise Resource Planning (ERP) system is another form of electronic commerce. It seeks to automate business process that span the organization, incorporating functions such as sales and materials planning, production planning, warehouse management, financial accounting, and personnel management into an integrated workflow of business events. ERP applications provide universal access to information across heterogeneous networks and data sources throughout the enterprise. While automating key internal business processes is an important step toward integration, integrating processes and information with the information systems of key customers and suppliers is a real competitive advantage. Sharing ERP data among business partners can streamline value chain processes, automate purchasing or customer service applications for real-time processing, and reduce the cost of order processing and financial transaction management. SAP, one of the leading vendors in the ERP space, has already recognized the need to extend R/3, their ERP solution, to address supply chain management. Unlike ERP systems, supply chain systems must cope with the complexity of integrating information from any number of disparate information systems spanning the entire length of the supply chain. In response, SAP has exposed business components within the R/3 system to applications compliant with open standards such as DCOM and CORBA. Like EDI, ERP installations are not only proprietary but also involve substantial investment, which limits these solutions to larger companies. Because they focus on the enterprise, there are even fewer standards that link the ERP systems of different companies. Technologies and standards that bridge the gap between ERP and EDI or Web-based systems are virtually nonexistent. XML has the promise to extend ERP beyond the bounds of the enterprise to achieve higher levels of intercompany and multivendor interoperability. 173

WEB-TO-HOST ACCESS TECHNOLOGIES THE WEB The Web has changed the face of business. Advertisements now feature URLs, and many organizations support sales over the Internet. Consumer Web users can browse catalogs, select items, and make purchases from the comfort of their living rooms. But Web-based shopping is only the tip of the electronic commerce iceberg. While much of E-commerce has been consumer oriented, the Internet can also be used to drastically improve efficiency, reduce costs, and increase sales for an organization by automating the businessto-business relationships with suppliers, distributors, and other partners. Without realizing it, organizations have already established a viable set of services, available on the World Wide Web and addressable by URLs. Existing Web services span the spectrum from package tracking and online banking to procurement and supply chain integration. Companies have looked to the open standards of the Web as a common means to communicate with their trading partners. Legacy databases, mainframes, and even EDI systems have been exposed via HTTP and HTML. The Web has truly become an integration platform. However, HTML-based applications assume that a human is interacting with the system through a Web browser, browsing catalogs and placing orders. While this approach is appropriate for a casual shopper, it is not the most efficient design for business process-driven applications such as supply chain management. For greatest efficiency, the intercorporate supply chain should be automated to work without human intervention. For example, as inventory levels are depleted, the ERP system should automatically query suppliers for inventory levels and delivery schedules, and automatically place orders for replacement stock. Although the information and processes to query and place orders might already be integrated with the Web, they are not designed to support external automated interfaces. Therefore, new interfaces need to be created to support Internet-based supply chain automation. THE NEED FOR BUSINESS-TO-BUSINESS INTEGRATION Solutions such as EDI and ERP focus only on providing software for automating operations within tightly coupled organizations. For an organization to achieve full benefits from electronic commerce, a solution must automate the operations between trading partners. An integration solution must cope with the complexity of integrating information from any number of varied information systems, spanning the entire length of the E-commerce continuum. A solution must provide a secure and reliable mechanism to communicate between applications; the message format must be open and flexible enough for different applications to understand, process, and respond to it. 174

XML-Based Business-to-Business E-commerce Some users are looking toward XML to solve the problem of business-tobusiness integration. XML may be the emerging standard that promises to bridge the communication gap between enterprise resource planning, electronic data interchange, and Web-based systems. Its real significance may emerge as a means for making it easier to create, deploy, and manage integration solutions over the Internet. WHAT IS XML? XML (eXtensible Markup Language) is a universal standard for data representation that can encode documents, data records, structured records, even data objects and graphical objects. XML documents are ASCII files that contain text as well as tags identifying structures within that text. This enables XML to contain “meta data” — data about the content in the document, including hierarchical relationships. As such, XML is a standalone data format that is self-describing. The following example illustrates how a purchase order might be represented using XML. 1001 <Status>Pending The ABC Company <SKU>45669 Modem Cable 9.95 <SKU>35675 Modem 99.95 A business application can locate a particular element and extract its value, regardless of the order of the elements within the document, and regardless of whether it recognizes all of the elements. INTEROPERABILITY WITH XML XML offers a lot more flexibility and extensibility than traditional messaging. The application that publishes the XML document could add a new attribute to the document, such as “Quantity,” to support the requirements of another application. The original applications that used the document 175

WEB-TO-HOST ACCESS TECHNOLOGIES would be unaffected by the additional attribute since they may only be interested in the SKU, Description, and Price of the Item. An XML document may be fully described by a Document Type Definition (DTD). An XML DTD specifies the format for a particular XML document type and identifies what tags must or may appear within the document. An XML document may contain or reference a DTD, in which case the DTD may be used to validate that the document matches a specific format. DTDs may be utilized to define standard vocabularies, designed for specific communities of interest. For example, the messaging formats for partners along the supply chain could be specified by a common DTD. XML Alone Is Not Enough XML is an open standard, which leads us to a Utopian perception of automatic interoperability. However, XML alone does not provide a complete integration solution, but it represents a central piece of the puzzle. Integrating applications with XML actually requires a fair amount of work. Applications have to be able to understand, process, and respond to XML message formats. Although the two applications do not need to agree on a specific message format, they still must reach consensus on the meaning of the data being passed. The two different applications are very likely to use different DTDs, and they must establish a way to match elements and attributes from one DTD to the entities and attributes in the other DTD. In most circumstances, it is not enough to simply pass information from one application to another. The sending application has to tell the receiving application what to do with the data. Therefore, the two applications need to agree on a mechanism for specifying what should be done with the data. A complete B2B solution would supply mechanisms that relate one application’s data structures to those of another. And it would provide a mechanism for requesting specific services to act on the information. Combining XML and integration software brings us closer to a B2B integration solution. AN XML-BASED B2B INTEGRATION SOLUTION Although it is extremely powerful, XML by itself cannot deliver application integration. Application integration involves much more than selfdescribing, extensible message formats. The application must be adapted to learn to communicate using XML. It must be able to route requests, manage tasks, and translate between messages conforming to different DTDs. 176

XML-Based Business-to-Business E-commerce Supplier Your Company

Supplier Web Site

XML HTML

Excel Spreadsheet Reseller Java Applets

Integration Server

XML

C/C++, Visual Basic PowerBuilder

ERP/MRP Applications

Internet or Intranet

Web Site

XML HTML

XML

Integration Server

Supplier ERP/MRP Applications

Databases

Exhibit 14-1.

Integration server connecting applications to applications and applications to Web sites, over the Internet or an extranet, enabling the integration of business processes between trading partners.

A complete solution must also provide the integration between other internal or external systems. The application that implements such a solution as an “integration server.” The integration server exposes a collection of integration services to XML-enabled clients. An integration service in the most generic sense is addressable by name, and it has a set of inputs and a set of outputs. The integration server provides the mapping of XML messages in and out of integration services. Exhibit 14-1 illustrates how such a solution might support Web and application integration between multiple corporations based on an XML messaging mechanism. The environment provides a central integration point to support XML-enabled client applications and provides access to both internal and external resources. XML AS THE RPC MESSAGE FORMAT An application that requests a service of another application must issue a message to the other application. For the purposes of this discussion, such a message is referred to as a Remote Procedure Call (RPC). An application issues an RPC by packaging a message, sending the message to the other application and then waiting for the reply message. Integration servers can combine the power of RPC middleware with the flexibility of XML to build a highly extensible, intercorporate integration 177

WEB-TO-HOST ACCESS TECHNOLOGIES system. XML RPC passes data as self-describing XML documents, unlike traditional RPC middleware systems that use a fixed, predefined message format. Formatting the messages using XML makes all B2B integration solutions highly flexible and extensible. XML RPC performs all communications over HTTP using standard HTTP get and post operations. The contents of the XML RPC messages are standard Internet traffic: XML documents. XML RPC obviates the need to open firewalls to traditional middleware protocols such as DCOM or IIOP. MAPPING BETWEEN DIFFERENT DTDs The integration server must be able to map between different XML data formats, or DTDs. WIDL (Web Interface Definition Language)1 provides such mapping capabilities and allows applications to communicate with each other via XML, regardless of the DTD they conform to. WIDL provides document mapping by associating, or binding, certain document elements with application variables. Data bindings may be used to extract some or all of the information in an XML or HTML document. The following example illustrates the use of WIDL binding with the XML document presented in the earlier example. doc.OrderNumber[0].text doc.LineItem[].SKU[0].text An application would apply this binding to the XML purchase order document in the first example to map the order number and the list of SKU numbers to the variables OrderNumber and SKU. Only the variables defined by the WIDL binding are exposed to the application. The variables within a WIDL binding abstract the application from the actual document reference, even from the XML data representation itself. An integration server would be able to apply similar bindings to a variety of XML formats to achieve the mapping between different DTDs. Exhibit 14-2 illustrates the benefits of this capability. Here, industries and businesses have defined a variety of DTDs to which different RPC encodings conform. The interface defined with WIDL captures a superset of the services and data available through the DTDs. Although different client applications speak different XML encodings, the integration server is able to bridge these differences and make the application universally accessible. This approach enables different organizations to construct loosely coupled application integration schemes. One organization may want to establish 178

XML-Based Business-to-Business E-commerce

XML

Integration Server

Internet or Intranet

Simple DTD

Consortium Client Industry Leader + Consortium Client Industry Leader Client

Exhibit 14-2.

XML

Consortium DTD Industry Leader DTD

WIDL Interface

Simple Client

Back-End App (e.g. ERP/MAP, E-Commerce System, or Database App)

Using WIDL to make different XML messages interoperable.

electronic integration among many different partners. Each partner maintains electronic relationships with many other partners. It is extremely difficult for such a loose partnership organization to reach agreement on a single set of message formats. But XML DTD mapping bypasses the need to reach total agreement. Each organization can define its own DTD. An integration server would automatically resolve the differences and deliver information to an organization in the format that the organization requires. EXPOSING APPLICATION SERVICES Application services provide access to certain resources, which the integration server exposes to other XML RPC-based applications. The integration server decodes the XML RPC request, identifies the service requested by the RPC, and passes the request on to the service in a data format it understands. It then encodes the output of the service as a properly formatted XML RPC reply that the client is able to understand. The application service provides the actual integration with internal or external resources, such as the Web, databases, EDI, or ERP systems. The implementation of a service, therefore, is completely abstracted from the message format. XML-based integration solutions actually XML-enable the systems they are integrating. For example, an integration solution might support the direct integration of different ERP systems across the Internet. A manufacturer running SAP R/3 can integrate its procurement system with the order processing system at a supplier running Baan. The integration solution is implemented separately from the application systems. No modifications are required within the back-end ERP application systems. In addition to providing a centralized switching system to support intercorporate communications, an integration server might also host business logic modules that tie the entire environment together or that add additional services to the integrated applications. 179

WEB-TO-HOST ACCESS TECHNOLOGIES EXPOSING WEB SERVICES An integration solution must also be able to leverage the vast quantities of information available on the Internet. It must provide unmanned access to Web resources, without a browser, and allow applications to integrate Web data and services. Programmatic access to the Web may also be referred to as Web Automation. WIDL enables Web Automation by defining Application Programming Interfaces (APIs) to Web data and services. Using its data bindings, WIDL is able to extract data from fields in an HTML or XML document and map them to program variables. WIDL abstracts the application from the actual document references (i.e., where the data being mapped actually exist in a page). Web Automation makes complex interactions with Web servers possible without requiring human intervention. An integration server exposes Web services as regular integration services. With an XML RPC, client applications are able to invoke a Web service, provide a set of inputs, and receive a set of outputs. The client is abstracted from the actual implementation of the service and is not concerned whether data was derived from a Web site, a local database, or remote ERP system. AN INTEGRATION STRATEGY Companies must be able to achieve application-to-application integration by leveraging existing investments in legacy- and Web-based products and technologies. An integration server provides a transitional strategy for integrating the systems and processes of trading partners into the corporate infrastructure. Look at an example. A manufacturer aims to integrate with a number of suppliers. If a supplier does not yet have a Web presence, it would be free to choose a Web-enabling technology that best suits its environment. By deploying an integration server, the manufacturer could incorporate its suppliers’ Web services into its procurement process, for instance. To accomplish even tighter integration, the supplier could expose internal data by adding XML markup to its existing Web offering. The final step in achieving complete application-to-application integration occurs when a supplier also deploys an XML-enabled integration server. CONCLUSION Business-to-business integration delivers significant cost savings and operational efficiency through business process automation and just-in-time supply chain management. Traditional EDI is cost prohibitive for most organizations, so the industry is turning to Internet-based B2B E-commerce. XML is a tremendous enabler. Using XML, applications can implement 180

XML-Based Business-to-Business E-commerce loosely coupled integration services that are flexible and extensible. But XML by itself will not provide automatic interoperability. Application integration requires infrastructure services to support reliable and secure performance. An integration server provides the infrastructure services that XML lacks. The growth of electronic trading networks depends on access to diverse data and information sources that reside in various formats in electronic catalogs on the Web, legacy databases, EDI, or ERP systems. Suppliers that can provide solutions that interoperate with multiple and diverse trading networks will become the dominant players in the electronic commerce arena. And their customers will become the earliest winners in the extended enterprise. Notes 1. In September of 1997, WebMethods, Inc. submitted the original WIDL specification to the World Wide Web Consortium (W3C). In October, the W3C acknowledged WIDL for its significance as an IDL and for its significance as a technology for programmatically accessing the Web. The W3C makes the submission available at the URL: .

181

Section III

Host Application User Interface Rejuvenation ONE OF THE COMPELLING BUSINESS DRIVERS FOR CLIENT/SERVER COMPUTING in the late 1980s and early 1990s was the achievement of a new, more productive user interface. Legacy applications are noted for their hostile, character-based user interface. With the emergence of PCs in the 1980s, the replacement of this dated user interface with a graphical user interface quickly became a goal of many IT organizations. However, for many reasons, client/server failed to completely revamp the world of legacy applications. The Web has provided a new paradigm and a new standard for user interfaces: the point-and-click hyperlinked world of multimedia documents and applications. Tools now exist that allow a new, rejuvenated, Web-style user interface to be wedded to existing legacy applications. Chapters 15 and 17 discuss different methodologies available today, while Chapter 16 provides some general guidance for designing usable Web-style interfaces for applications.

183

Chapter 15

Web-Based Technologies for User Interface Rejuvenation Todres Yampel

WHAT DOES IT MEAN TO WEB-ENABLE ENTERPRISE LEGACY APPLICATIONS? While there are many issues involved in Web-enabling legacy applications, they can generally be grouped in two categories: providing secure Web browser-based access to legacy hosts and delivering a more modern graphical, browser-like familiar look-and-feel. This is often collectively referred to as rejuvenating legacy applications. WHY WEB-ENABLE LEGACY APPLICATIONS? The most powerful driving force behind the push to integrate enterprise applications with the Internet is the need for efficient services. The more these services can be converted into automated self-services, the fewer operators are needed behind the help desk. Everyone knows the model established by the early pioneers in the shipping industry — FedEx and UPS. These companies understood early on, even before the arrival of the Internet, the importance of offering users the option of self-service by providing package tracking information online from their computers. Many more companies followed suit and now it is quite common to find train and plane schedules on the Web. And as the experience of getting such information from the Web becomes more positive than calling for such assistance over the phone, more and more users will demand that access to such data be available around the clock from all over the globe.

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

185

HOST APPLICATION USER INTERFACE REJUVENATION OBSTACLES IN WEB-ENABLING LEGACY APPLICATIONS There are still too many companies with large staffs devoted to answering questions by phone regarding the status of certain financial transactions or tracking the movement of “widgets.” The impact of widespread mergers of corporations in response to the globalization forces makes unimpeded flow of information among departments, branches, and divisions more important than ever. A Web server-based distribution and sharing of information is an obvious solution, even if the Web server is limited to internal users only. There are few reasons why so many corporations are lagging behind in opening up the enterprise legacy systems to the Internet or even intranet users. The primary reason for this is, of course, the Y2K curse, which forced all other projects involving legacy applications either completely “off the radar” or to a very low priority for the IT center. Even in the last quarter of 1999, most legacy systems were usually off-limits to any enhancements, frozen in some strange “lockdown” mode. While the technologies to access the legacy applications from Web browser-based clients were developing rapidly,1 there remained one major obstacle — the archaic “green screen” user interface. While such interfaces were originally designed with the goal of delivering great efficiencies for the trained “heads-down” users, they are far from being intuitive for new users without extensive training. Many CICS-based applications, for example, require users to clear the screen by pressing a specially designated key, then enter a four-character transaction code followed by some cryptic set of parameters; these have to be entered in proper order with correct delimiters. While the cost of connecting occasional users to legacy applications is minimal, training costs to make them efficient are quite high. In addition, more and more users are resisting such training as a waste of time, associating it with acquiring obsolete technology skills. Thus the obvious need for “rejuvenated” user interfaces. WHAT DOES IT MEAN TO REJUVENATE LEGACY APPLICATIONS? In the narrow sense, rejuvenation means making the user interface more familiar and intuitive to novice users. This is achieved by replacing the need for pressing exotic keys with clicking on properly labeled buttons. How many users, for example, can correctly guess that the prompt “PRESS PF13 FOR MORE DETAILS” means pressing together the F1 key while holding down the SHIFT key at the same time? A “rejuvenated” interface places a macro button on the screen that is labeled “More Details.” When the user clicks on the button, the code representing the “PF13” is sent to the host computer. 186

Web-Based Technologies for User Interface Rejuvenation Another important rejuvenation feature is the replacement of blank entry fields with rectangular text entry objects, which right away gives a formslike look to screens. In a broader sense, however, rejuvenation of legacy applications is more akin to remodeling a kitchen. One does not just replace the old appliances with the more modern models; one ends up adding some new ones — perhaps a dishwasher here, a microwave oven there, etc. In rejuvenating legacy application projects, this translates into adding list boxes, help files, combining data from other sources, and exchanging data with other applications, such as spreadsheets and databases. OPTIONS FOR REJUVENATING LEGACY APPLICATIONS The industry responded to the challenge of rejuvenating legacy applications by delivering a variety of solutions. This chapter provides a brief review of the competing approaches and describes in more detail one possible best solution in the market today. Toolkit Approach The toolkit approach is based on delivering development tools on top of the traditional “green screen” emulation products. Typically, these are “wizards” that produce Visual Basic or Java code. With these tools, users are constructing the new screen or form using various objects from the toolbar. The “green screen” emulation program shows the original host screen via “live” connection in a separate window, from which users dragand-drop the fields they need. In the final step, the form is compiled and an ActiveX object or a Java applet is produced. While this approach seems easy at first, the reality is quite different. The wizards, for example, have no way to distinguish a literal on the screen from protected output fields, generated by the application, before turning it into a label or a button. Very frequently, fields that are changing dynamically, such as dates and time stamps, are treated as static literals. It usually takes a few days until somebody notices that the dates on the rejuvenated screens are always the same; now some serious tweaking of the generated code is required. It is not uncommon for users to give up at this point and hire the vendor’s consultants to do it right. This, in turn, gives the consultants the opportunity to add all kinds of “extras” to the project — for example, ODBC/JDBC data links to combine host data with data from other enterprise sources, Web links, special validation rules, etc. Once custom programming is introduced, the number of enhancements is limited only by the available time and money resources. Generating custom objects per screen adds to the footprint of the resulting clients and adds to bandwidth requirements for the network. This 187

HOST APPLICATION USER INTERFACE REJUVENATION Exhibit 15-1.

Pros and cons of the toolkit approach.

Pros Highly customizable Extent of customization limited only by expertise of consultants and resources at their disposal

Cons Long implementation cycle Sluggish performance High cost Maintenance and support are critical

is especially problematic in the case of Java applets, which have to be downloaded on demand from the Web server. Even if the applets are cached by the browser, starting them is a time-consuming process as the browser has to verify all classes being loaded and check them against the allowed range of security privileges. This may add a couple seconds to response time. While three to eight seconds may seem tolerable to Web users accustomed to long waits on the “World-Wide Wait” network, it may be totally unacceptable to users expecting subsecond response time from their mainframes. That is the reason why these solutions are more suitable to intranets or extranets, where the required bandwidth as well as powerful workstations can be more easily guaranteed. The other major problem with this approach is that the generated code contains some portions of the business logic. If the users change the host applications at some later time, they have to recall the consultants to modify the rejuvenated code as well. This can easily turn into a maintenance nightmare and an unhealthy dependence on the original consultants. Exhibit 15-1 summarizes the pros and cons of the toolkit approach. Knowledge-Based Approach This approach relies on access to files used to generate the maps of the legacy application. These files are then analyzed and a screen “album” is generated. This album serves as input for the second phase — creating templates and refining them by applying a set of rules. For example, an occurrence of a string “F12=EXIT” is deemed a good candidate for a substitution by an “EXIT” button, which, when clicked on, sends the code emulating the pressing of the F12 function key. More troublesome, however, is the occurrence of the string “ENTER.” While it makes perfect sense to convert the phrase “PRESS ENTER TO CONTINUE” into a button “CONTINUE,” it is totally wrong to do the same in the case of “PLEASE ENTER YOUR ACCOUNT HERE.” This is when the multitude of rules come into play. Some vendors proudly boast of having over 700 rules in their products. It usually takes months for users to master these rules. In the final phase, programming code is generated, which is then compiled into either ActiveX or Java applet objects. If any additional features are needed, they are added manually with 188

Web-Based Technologies for User Interface Rejuvenation Exhibit 15-2.

Pros and cons of the knowledge-based approach.

Pros Highly customizable Extent of customization limited only by expertise of consultants and resources at their disposal

Cons Long implementation cycle Sluggish performance High cost Maintenance and support are critical Steep learning curve causes dependence on vendor’s consultants

custom code. At this point, the approach is similar to the one with toolkits, with all its positives and negatives listed above. Having so many rules to deal with, these products typically require a server to handle them. It would be just too “fat” to reside on the client’s workstation, especially if implemented in Java to run under a browser. This, in turn, has implications for scalability and adequate response time. Exhibit 15-2 summarizes the pros and cons of the knowledge-based approach. Noncustomizable AutoGUI Approach This approach has the advantage of delivering immediate results, often “out of the box.” Such software dynamically, “on-the-fly,” converts input fields to rectangular text entry objects and detects occurrences of function key prompts and converts them into clickable hot spots. The approach is based on the premise that 80 percent of the screens in a given application are quite usable without any further customization. Since no programming is involved, there are practically no maintenance issues and the risk in using such software is extremely low. This approach, however, may not be suitable for the CICS applications described above, in which the user must first clear the screen and then enter a 4-byte transaction code with cryptic parameters. The extent of customization available with such software is usually limited to default settings of a cosmetic nature, such as color schemes, logos, etc. Exhibit 15-3 summarizes the pros and cons of the noncustomizable AutoGUI approach. Customizable AutoGUI Approach A final approach combines the ease of the noncustomizable AutoGUI approach with the flexibility of the other approaches. This approach, termed the customizable AutoGUI approach, • provides an AutoGUI capability for the 80 percent of screens that do not require customization 189

HOST APPLICATION USER INTERFACE REJUVENATION Exhibit 15-3.

Pros and cons of the non-customizable AutoGUI approach. Pros

Cons

Short implementation cycle Works “out of the box” Low cost Low risk Minimal maintenance and support requirements

May not be suitable for some applications

• provides customization tools to take care of the other 20 percent of the application screens in which some changes must be made • allows fields to be hidden from users that may be unnecessary or confusing • reduces error rates by supplying the list of proper values in a dropdown list • allows access to external data sources (e.g., tracking FedEx packages by simply clicking on the shipping reference field) • does not require customer programming, with its associated increase in risk and cost ResQNet, a product from New York-based ResQNet.com,2 is a product in this category. ResQNet is unique in its approach by being screen centric. The proprietary patented technology is based on the software’s ability to recognize an application screen by the unique “fingerprints” of the data stream representing it. Once the application screen is assigned its unique ID tag that is placed in a screen database, the rest of rejuvenation customization functionality is mostly delivered to this particular screen. The exception to this is functionality for profile settings, which is global in scope. The Customization Studio component of the ResQNet product gives users full control over the final look-and-feel of the rejuvenated screen. Every field on the screen is presented as an individual graphical object that can be moved, resized, and otherwise modified by drag-and-drop mouse movements. Users can easily modify appearance-related attributes such as color, font, and text of its caption by selecting options from the activated dialog box. Non-input fields such as literals or protected fields are by default turned into labels. The Studio has options to convert these labels into clickable macro buttons, which is especially useful for menu screens. This gives users the choice of either entering the proper menu option into the provided entry field or clicking on the description of the option, in which case the software enters the option for the user. The result is a more visually appealing screen that at the same time works in reducing possible typing errors as well. By changing the captions of the labels or converted buttons, users can in effect translate them into more suitable text. Users can apply this to literally 190

Web-Based Technologies for User Interface Rejuvenation translate the host screen into a foreign language, such as Spanish, or use it for clean-up and clarification purposes. For example, the notoriously cryptic all-caps host literals can be expanded into more understandable explanations utilizing easier to read mixed upper and lowercase letters. Fields on the resulting screen can be hidden with a simple click of the space bar. If there is a need to hide mandatory entry fields, this too can be accomplished with default values being passed to the host invisibly to users. More advanced rejuvenation features include navigational assistance options, such as Get-To-The-Point, playback of prerecorded keystrokes, Web-link buttons, and more. The aptly named Get-To-The-Point facility provides behind-the-scenes navigation transparent to the users, where entry fields on the screens are entered by the system from a set of prepared values, proper function keys are pressed, and the display of the host screen is suppressed as well. This is especially useful for granting access to Internet users, where user names, passwords, and other values are known ahead of time. The software can enter these values automatically, completely shielding casual users from VTAM logon sequences, CICS logon steps that involve clearing screens, and other such exotic stuff. Web-link facility is another popular feature worth mentioning. It provides ResQNet users with behind-the-scenes access to Web server-based facilities by constructing the appropriate URL and submitting it to a separate browser window. Say, for example, that the host application contains a shipper’s reference field, such as FedEx tracking number. Using the Customization Studio, this field can be converted into a Web-link button, which, when clicked on, opens a browser window with the URL constructed to point to FedEx’s Web site tracking page with the tracking number already filled out. The browser just brings back the resulting page, all without requiring the user to reenter the number again. Not even cut-andpaste action is required. There are many other features in the ResQNet product that make it suitable for enhancing the look-and-feel of the legacy application and for providing additional functionality that extends the reach of the legacy system by combining data from external sources, such as SQL databases, MQSeries middleware messaging systems, spreadsheets, and flat files. Describing these features is outside the scope of this chapter, however. Believing in the adage that a good picture is worth a thousand words, take a moment to examine screen shots of an actual legacy application, which happens to be an entry screen for a collection subsystem of a trade finance banking application. Exhibit 15-4 illustrates what this screen looks like when displayed by traditional “green screen” emulators. It is impossible to tell where the input fields are, because they are represented by “black holes.” Even when the cursor is in the entry field, users have no indication of the size of the expected entry. If they happen to exceed the allowed 191

192 CTRY ?

CITY? CTRY ?

PAYER NAME AND ADDRESS 1 2 3 4 5 6

REF # ? A/C # ? ACRONYM ? CITY?

Exhibit 15-4. Traditional “green screen” emulator display.

A/C # IS ROLLABLE BY ACRONYM PRESS ENTER TO EXIT PF1 -- NEXT SCREEN PF2 -- STANDING INSTRUCTIONS PF3 -- DRAWER/DRAWER SCREEN PF4/5 ROLL FWD/BACK ENTER PROTOTYPE OR ENTER ACCOUNT # AND REF # MA* a 07/080

PRESENTOR NAME AND ADDRESS 1 2 3 4 5 6

REF # ? A/C # ? ACRONYM ?

ID: DIO5 12/23/98 DC005M 15:46:27 082692 COLLECTION ISSUE CREATE WORKER ? PASSWORD ? ENTER WORKER NUMBER AND PASSWORD PROTOTYPE # ? CL PREFIX ? SEQUENCE NUMBER ? 000 SUFFIX ? CL NUMBER ? MICR # ? OFFICE ID ? PREPRC ? N Y/N PRESENTOR: PAYER:

HOST APPLICATION USER INTERFACE REJUVENATION

Web-Based Technologies for User Interface Rejuvenation length, here is what usually happens next. Typically, the keyboard locks up and a special indication appears in the designated status area of the screen under the solid line at the bottom. The user is now expected to press the RESET key, which is usually mapped to the left CTRL key. Users expecting the same “unlocking” effect by pressing the right CTRL key are in for a surprise — that key is mapped to work as the ENTER key, while the real ENTER key on the keyboard moves the cursor to the next line, faithfully representing the action of the NEW LINE key of the host terminal. Now, take a look at Exhibit 15-5, representing the same screen as rendered with AutoGUI software. This is the actual default look-and-feel users get “out-of-the-box.” Here, all input fields are clearly presented, which gives the screen the familiar look of an entry form. All prompts, referring to special function keys, are turned into so-called hot spots, where users unfamiliar with mappings for those keys can simply click on the dynamically created buttons. The cursor has the familiar look of a vertical line and the currently active entry field has a different background color. In addition, the software is providing automatic unlocking action without relying on the need to press the RESET key. Pressing any key, including the TAB and the arrow keys, unlocks the keyboard. This screen is much more friendly and easy to use for untrained users. It may even be completely satisfactory for most applications, especially those involving state or local governments that are under mandates to open up their databases to the general public. These organizations usually have no incentives to spend a great deal of effort to make the screens so appealing that users would want to come back for more. Indeed, for such cases, any additional customization efforts are a waste of taxpayers’ money. On the other hand, many companies have a stake in putting the best face possible to the outside users, such as their vendors, suppliers, or customers, current or potential. Take a look at Exhibit 15-6 to see how this screen can be transformed in 20 to 30 minutes of customization. Just adding a few frames around groups of fields on the screen makes the information look better organized and the screen much more visually appealing. The allcaps literals, which are such a giveaway of a mainframe application, are replaced by “normal” text. The prompts for function keys are gone, replaced by a group of macro buttons on the left side. A nice-looking company logo has been added. The additional Web-link button on the left side of the screen provides users with access to the company’s Web site. Context-sensitive help and valid values are provided, where users can get detailed descriptions of the required codes as well as possible valid values. This information, of course, is coming from the Web server-based sources, rather than the mainframe. Users, looking at such a screen, may not even suspect that it originated from a dated mainframe application.

193

Exhibit 15-5. Rejuvenated screen using AutoGUI software.

HOST APPLICATION USER INTERFACE REJUVENATION

194

Exhibit 15-6. Rejuvenated screen with customization.

Web-Based Technologies for User Interface Rejuvenation

195

HOST APPLICATION USER INTERFACE REJUVENATION Exhibit 15-7.

Pros and cons of the customizable AutoGUI approach. Pros

Cons

Quick implementation Low risk Minimal maintenance and support requirements High level of customization without programming

All the customization illustrated in Exhibit 15-6 is done without any programming or scripting. Nor is any generated for subsequent compilation at any phase of the process. A mouse and a keyboard are all that are needed. Exhibit 15-7 summarizes the pros and cons of this approach. CONCLUSION There seems to be a consensus among industry watchers that Web-enablement projects will be the next “hot” item for IT departments after Y2K-related ones fade off the radar screen. Among many available approaches, most solutions available today do not require any change whatsoever to the legacy applications. Of course, there are some solutions, most of them from IBM, that are host centric. The main thing to remember is that there are no legitimate reasons for not implementing these solutions. Security, cost, risk, speed of implementation — all these issues have been properly addressed by the industry and leave IT managers without any excuses for keeping their enterprise legacy systems out of reach for intranet, extranet, or Internet users. Notes 1. For more information on TCP/IP and Web browser technologies, see Anura Gurugé, Integrating TCP/IP I•nets with IBM Data Centers, Addison Wesley Longman, 1999. 2. ResQNet may appear in the market under different names since it is licensed to IBM and other vendors.

196

Chapter 16

Usability Design for Web-based Applications Chris Forsythe

UNTIL RECENTLY, MOST WEB-BASED DEVELOPMENT WAS CONDUCTED IN an atmosphere largely forgiving and tolerant of the shortcomings associated with World Wide Web technologies and their interfaces. Most organizations had only one or two knowledgeable Web developers who were rarely challenged to meet standards comparable to those for traditional software applications. Web sites providing unique information or services encountered little or no competition from similar sites. Although there was no shortage of enthusiasts, expectations were generally low and interest was sustained merely by the Web’s novelty and potential. Similarly, the relatively small number of total potential users meant that any gains or losses resulting from a high-quality or poorly designed Web application were mostly small, if not nonexistent. As Web technologies have matured, much has changed. Today, the business operations of many corporations hinge on the effectiveness and efficiency of their intranets, and the development of Web marketing strategies is a must. In more and more cases, Web technology is being used to provide resources that greatly enhance the capacity to conduct work. Furthermore, the availability of immediate cross-platform solutions and the relative ease of applications development make Web-based applications the most practical software solution for many organizations. The evolution of Web technologies from a plaything to a legitimate business tool has generated expectations that Web applications will perform just as well, if not better than common commercial software. Over the past ten years, the commercial software business has been driven by usability and the need to provide users with an intuitive, error-tolerant, efficient, and productive user interface. This should not have come as any surprise, because it is fairly obvious that software that allows more work to be done, 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

197

HOST APPLICATION USER INTERFACE REJUVENATION better and faster, is far preferable to less usable software. The same relationship between usability and business success also exists regarding Web user interfaces. USABILITY BASICS In the late 1980s, an interesting phenomenon began to occur in the commercial software business as marketing people and materials started to tout software as user friendly, based on implementation of a graphical user interface (GUI). Because a GUI was thought to be the singular ingredient necessary for attaining user friendliness, often little else was done for the sake of usability. This phenomenon has left the term “user friendly” so overused and misused that it no longer has much meaning. Just as GUIs were once touted as the one element needed to achieve usability, today, a Web front end is often cited as the basis for asserting the usability of Web-based products. As was the case for GUIs in the 1980s, these claims typically go unchallenged, and organizations purchase too many products without requesting proof of their usability. How is usability attained? There are many approaches, and the one chosen depends on the importance of the software. If software is to be frequently used by large numbers of people or for critical activities, or both, the approach followed should provide a high level of assurance that usability is attained. Such an approach may include job analysis and task analysis, followed by rapid prototyping interspersed with frequent usability testing. In contrast, if there will be limited numbers of users and the software and its functions are noncritical, it is often sufficient for the developer simply to adhere to design guidelines and obtain informal peer reviews. The importance of software usually varies between these two extremes, so the level of effort devoted to ensuring usability is varied as well. COST JUSTIFICATION Common Misconceptions The most common misconception about usability among a broad range of software developers and engineers from various disciplines is that usability is largely common sense. Were common sense and good intentions all that is necessary to consistently produce usable software products, the term “computer anxiety” would never have become part of today’s common vernacular; companies would not have to commit substantial sums to training, help desks, and other user support services; and there would not be such a high incidence of companies investing capital to computerize their business processes only to achieve marginal improvements in productivity. 198

Usability Design for Web-based Applications The misconception that usability is only common sense does not only promote the delusion that usability can be attained at no expense, but also perpetuates the misapplication of talented software developers to the job of user interface design. This task distracts these individuals from the challenges of code development and without the necessary know-how is only rarely a source of great rewards. Usability comes at a cost. Most corporate software development projects involve significant technical challenges that consume the bulk of both financial and human resources. To commit to usable design requires that resources be diverted from the core code development to various activities associated with the definition, prototyping, testing, and refinement of the user interface. Furthermore, a usable interface often imposes requirements on the supporting software that are inconvenient and met only by overcoming certain difficulty. The net result is that software, Web-based or otherwise, with a highly intuitive user interface is likely to cost more to develop than if usability were neglected. The trade-off that results from weighing the importance of the software against the level of effort devoted to development of the user interface increases in importance as corporations automate their business practices and pursue information-driven processes. Usability costs must be paid, whether they are incurred through up-front development costs, training costs, lost productivity, or technology rejection and abandonment. The most cost-effective approach for applications that will be used frequently by a large number of users and involve operations for which errors may have costly and otherwise undesirable consequences is almost always to shift costs to development and make the investments necessary to ensure usability. Case Study The case of a hypothetical Web-based time-card application demonstrates this costing logic. The application is to be used once per week (a conservative estimate given that most employers encourage staff to make time-card entries daily, if not more frequently) by 8000 employees. Experience with many such Web-based applications makes it reasonable to assert that thorough involvement of usability specialists in the development of the time-card will reduce the average transaction time from four to three minutes. This reduction results from improving the efficiency of transactions and reducing the likelihood of errors. Such improvements may be gained in many different ways. For example, integration of two pages into one avoids lost time as users wait for pages to download across busy networks. Similarly, providing immediate access to supporting information such as time-charging codes could yield equivalent savings by avoiding 199

HOST APPLICATION USER INTERFACE REJUVENATION the need for users to go to another location and search for necessary information. Finally, presenting text and data in a readable format can easily prevent errors in data entry, reducing the likelihood of an erroneous timecard from 5 percnet to less than 1 percent. Presuming an average cost for employees of $50 per hour, the following savings are calculated: 1 min/employee * 8000 employees = 8000 min 50$/hour —————— = $0.83/min 60 min/hour $0.83/min ∗ 8000 min = $6640/week $6640/week ∗ 52 weeks/year = $345,280/year $345,280/year ∗ 5 year life span = $1,726,400 savings

These savings only address the cumulative sum of lost productivity. These same improvements to the user interface would also serve to reduce the time required for training, regardless of whether training occurs formally or informally. Although it should be possible to develop an interface that is sufficiently intuitive to obviate the need for training, for the present purposes a reduction in average training time from 30 to 15 minutes is assumed. Such a reduction leads to the following additional savings: 15 min/employee ∗ 8000 employees = 120,000 min $0.83/min ∗ 120,000 min = $99,600 savings

Still, the savings do not stop here. Typically, this type of application necessitates some type of user support, whether formally through a help desk or informally through co-workers answering each other’s questions. Once again, it is reasonable to assert that improvements to usability would result in a reduction in the number of employees who seek assistance on at least one occasion from 15 percent to 5 percent. Without even considering that some employees may not only seek assistance, but seek assistance on multiple occasions, further savings are calculated as follows: 10% fewer employees seeking assistance = 800 employees Average time spent on assistance = 15 min ∗ 2 employees = 30 min 30 min ∗ 800 employees = 24,000 min $0.83 * 24,000 min = $19,920 savings

In this example, the savings realized from a 10 percent reduction in the number of first time requests for assistance should cover a good portion, if not all, of the costs incurred from including a usability specialist on the interface design team and conducting usability testing. Granted, accommodating 200

Usability Design for Web-based Applications usability within the software design may also increase software development costs because the most usable design is often not the easiest to develop. These costs, however, should also be dwarfed by the sum of the potential savings. The decision to design for usability is always a matter of cost transfer. Designing for usability transfers cost to development. When usability is neglected, either intentionally or inadvertently, a decision is made to transfer costs to training and to the overhead charged to nearly every account to which employees allocate their time. The example of the Web-based timecard application illustrates that by paying a little more up front to ensure usability and transferring costs to development, substantial savings are realized over the life span of the software. By paying a little extra for usability, a buyer purchases quality and the long-range savings that accrue from it. THE WEB DESIGN CHALLENGE A plethora of sources offer guidance on interface design for Web-based applications. These sources include Web sites offering style guides or other design recommendations, books addressing Web page design, and Web developers willing to share their opinions. Given the newness of the Web and the relatively rapid evolution in the capabilities afforded by HTML and Web browsers, the amount of so-called expertise being offered on good and bad design practices is astounding. A recent study comparing Web design guidelines to traditional humancomputer interface (HCI) guidelines suggests the need for caution in adopting Web guidelines, regardless of their source. The study of 21 Web style guides found that the time devoted to Web design guidelines was less than one-twenty-fifth that devoted to traditional HCI guidelines. Furthermore, 75 percent of the more than 350 distinct design recommendations found appeared in only one style guide. This suggests that most of the advice being offered is merely personal opinion. The fact that only 20 percent of the 270 Web-relevant recommendations found in traditional HCI style guides appeared in any of the Web style guides suggests that existing, readily available knowledge concerning user interface design is largely ignored. The study also asked a group of human factors practitioners to rate the importance of each of the 270 Web-relevant recommendations found in the traditional design guides to the usability of an interface. Of the 20 recommendations rated most essential to usability, only one was found in any of the Web design guides. Thus, Web design guides do not only fail to address much of what has traditionally been accepted as effective user interface design practice, but they also fail to consider those facets of design most essential to usability. It is generally recommended that developers of Web-based applications approach various sources of design guidance with due skepticism and follow 201

HOST APPLICATION USER INTERFACE REJUVENATION instead the rich body of knowledge relating to user interface design, including guidelines, evaluation, and testing. This well-researched, widely accepted, and generally reliable source of Web-relevant guidance contains the collective knowledge of hundreds of practitioners derived from countless hours of laboratory and field research concerning facets of user interface design that either contribute or distract from usability. ATTAINING USABLE WEB-BASED APPLICATION INTERFACES The surest formula for attaining usable Web-based application interfaces is to follow a process that incorporates the identification and resolution of usability concerns into every phase of the interface design. This process involves up-front analysis to gain an understanding of the user and the job. There is no more frequently cited heuristic within human factors than “Know thy user and you are not thy user.” In essence, this heuristic instructs interface designers to make no assumptions regarding what the user needs, prefers, understands, and can use. Most important, just because software may seem easy and make sense to the development team does not mean that the user will be able to understand and use it. As the interface is developed, designers should follow established guidelines regarding usability design. Lastly, nothing should be taken for granted. Thorough usability testing should be conducted with representative users applying the software, or reasonable prototypes, to perform tasks representative of those for which the software is intended. Although usability is largely achieved through the process followed in developing the user interface, a great deal of knowledge regarding the facets of design contributes or distracts from an interface’s usability. The following sections present some of the HCI guidelines judged most essential to Web usability by the group of human factors experts in the previously discussed study. The guidelines illustrate the effects that specific user interface design decisions may have on the ability of users to successfully apply software to accomplish their work. Direct Usability of Information Information should be presented in a directly usable format that does not require decoding, interpretation, or calculation. This means that users should not be given an answer that requires them to seek other references for its interpretation. Although incorporating various reference documents into an application may greatly expand the scope of the application, such additional labor is typically paid for many times over through the resulting increased productivity. Furthermore, not incorporating these references assumes users both possess and know how to use them. 202

Usability Design for Web-based Applications Similarly, users should not be required to use items such as calculators for operations that an application can be programmed to perform. This is because of the probability of human error resulting from reading values from a screen and entering those values by a keypad or keyboard. Ease of Navigation through Data Displays When displayed data exceeds a single display, users must have an easy mechanism for moving back and forth through material. The most common violation of this design principle regarding Web-based applications occurs when reports are written from a database directly into an HTML file and the resulting table extends beyond the right border of the browser window. The likelihood of error is introduced because users must awkwardly scroll back and forth and may lose track of the row from which they are reading. In these cases, the costs of thousands of users scrolling back and forth and losing their places within data reports must be weighed against the additional effort required to reformat the reports for display with minimal or no scrolling. Concise Instruction Levels Users should not be expected to read more than three help displays or remember more than five points. This statement from traditional HCI sources may be too lenient for Web-based applications because, strangely, users exhibit a much lower tolerance for written instructions presented through Web interfaces than through traditional computer text displays. Thus, for Web-based applications, the requirement for concise, to-thepoint help is considerably more stringent and requires greater attention to the content of help systems than might be expected. Consistent Use of Color Color should be used consistently within a display or across a set of displays because misinterpretations result from the fact that users both intentionally and unintentionally attribute meaning to colors. Unfortunately, developers often choose colors for aesthetic reasons and fail to consider the unintended meanings users assign to them. Throughout the design of an interface, therefore, the developer must assume that users will assign meaning to colors and exercise care in their selection and use. Distinct Naming Similar names for different functions should be avoided. This is because in choosing items from a menu, pull-down list, or table, especially with familiar interfaces, users often discriminate solely on the basis of the general outline of the selection without actually reading the words. For this reason, the labels placed on buttons, in menus, or as list items should be distinct, both semantically and with regard to the visual appearance of the words themselves. 203

HOST APPLICATION USER INTERFACE REJUVENATION Indication of Function Actuation A positive indication of function actuation should be provided. This guideline has particular ramifications for Web-based applications. In many respects, Web browsers provide the subtlest of cues that user actions are having an effect. The user cannot be assumed to recognize that a selection has been made on the basis of flying meteorites or spinning electrons that appear against a small graphic within the browser window. For these reasons, other cues that a user action is having an effect should be provided. For example, most Web users are familiar with the concept of pages wherein text loads before images. Similarly, for back-end processes requiring that the user wait, it is often possible to provide a message informing the user that a request has been received and is being processed. Likewise, for long, perhaps graphically intense downloads, the user may be provided with a confirmation message that the requested download is about to commence. Confirmation of Destructive Actions Users should be required to confirm potentially destructive actions before the action is executed. Although such confirmation requests are a standard feature in most non-Web user interfaces, this design practice has often been neglected with software developed for the Web. This situation is exacerbated by the ease with which Web developers may insert a Clear Form button that all too frequently is placed immediately adjacent to buttons used for frequent operations such as Submit. The common assertion that confirmation messages are a nuisance is usually made by experienced, frequent computer users and rarely by novice or infrequent users. Unless designing for a highly competent user population that has expressed its disfavor with confirmation messages, the developer should always err conservatively and include them. Efficient Data Input Data input actions should minimize user actions and memory load on the user. In short, any transformations, formatting, or similar modifications of user input should be done by the computer. It is unproductive for users to expend their resources performing various data manipulations to prepare data to be input into the application when these manipulations could be done by the machine. Logical Data Entry Formats Data entry formats should match source document formats. When a Web interface is used in transferring data from paper forms to electronic data files, the interface should mimic the paper form in sequence and layout as closely as possible. 204

Usability Design for Web-based Applications Automated Data Entry Data should be automatically entered in a field when it is known or can be computed. Once again, overall productivity is served when writing a few extra lines of code to perform an operation or filling in data accessible from one or more databases results in the transfer of work from the user to the machine. Similarly, if the user has entered data once, it should be filled in later and not require reentry by the user. Simplified Data Entry Rules Complex rules for entering data should be avoided. In general, flexibility should be the rule. For a social security number, for example, the user should be allowed but not required to use dashes. For a phone number, users should be allowed to enter the area code; but if they do not, it should be determined by the machine based on the three-number prefix. For every data input, therefore, consideration should be given to the various formats by which a user might naturally enter the data. To the extent allowed, all such formats should be accommodated by stripping away excess punctuation and referring to translation tables or other similar mechanisms. Required and Optional Field Differentiation Cues should be given to distinguish required from optional fields. Many applications request information that is useful, but not necessary. Because users often assume every space must be filled, they devote inordinate amounts of time to searching for information, the benefit of which is far outweighed by the cost of its retrieval. Thus, unless it is truly necessary, users should have the option of skipping fields for which they do not readily know or cannot readily obtain the desired information. Feedback on Data Input The user should be provided positive feedback regarding the acceptance or rejection of data input. Many applications allow users to submit requests that will not be filled for several minutes or hours. In such cases, the user should be provided feedback regarding the acceptance or rejection of the request on submission, and not when the results are returned. In particular, this calls for routines that validate the user request prior to its submission for processing. Error Correction An easy mechanism should be provided for correcting erroneous entries. This mechanism should make it easy for the user to identify and correct any errors made. Should a request be rejected, the user should not be required to reformulate the request from the beginning, but be allowed instead to 205

HOST APPLICATION USER INTERFACE REJUVENATION correct only the erroneous entry and resubmit the request. Similarly, the application should provide sufficient details regarding the location and nature of errors so that correction is intuitive and easily accomplished. RECOMMENDED COURSE OF ACTION No one intentionally designs interfaces to be nonusable. At the same time, usability does not come without some expenditure. Consequently, in environments in which development costs and schedules drive design decisions, it is far too easy to neglect usability or assign it low priority. Too often, user interfaces are slapped together after all other functional elements are essentially completed. Similarly, design issues that are critical to the usability of the product are all too often relegated to the status of “nice to have.” It is interesting that a software bug that causes a 1 percent failure rate will receive endless hours of attention and result in the software ultimately being rejected. Yet an interface feature that causes users to fail to successfully complete 10 percent of their transactions with the software is considered trivial and not worthy of the precious time and resources required to correct the problem. Similarly, days of analysis, research, and testing are devoted to issues related to functional elements of the software code, but decisions regarding interface features that could be critical to the users’ success or failure are made off-the-cuff, with little or no discussion and rarely any analysis or testing. There is no shortage of excuses for failing to give usability its due consideration. In the end, however, the costs of this failure are paid through incremental drains on the overall productivity of the enterprise. Just because these costs are largely hidden does not mean they do not warrant correction. By following the guidelines presented in this chapter, organizations take the first basic steps toward attaining productive and usable Web-based application interfaces that ultimately aid, not hinder, business success.

206

Chapter 17

User Interface Rejuvenation Methodologies Available with Web-to-Host Integration Solutions Carlson Colomb and Anura Gurugé

THE

ABILITY TO EASILY , ECONOMICALLY , AND VERY DRAMATICALLY

rejuvenate the anachronistic user interface of mainframe and AS/400 applications is an integral, valuable, and widely publicized feature of most contemporary Web-to-host integration solutions. Schemes to facilitate user interface rejuvenation when it came to PC/workstation-based host access have also been readily available with traditional screen emulation solutions (e.g., Eicon’s Aviva for Desktops) for nearly 15 years. All leading 3270/5250 emulators offer the High-Level Language Application Program Interface (HLLAPI) or its equivalent, at a minimum, as one possible means whereby the harsh and dated “green-on-black” screens of SNA applications can be intercepted and totally revamped before they are presented to a user. However, it is sobering to realize that not even 25 percent of the millions of mainframe and AS/400 screens that are regularly displayed around the world each day with these traditional access solutions have been rejuvenated. “Green-on-black” is still the norm when it comes to IBM host access. A kind of cultural inertia has prevailed up until now that believed that “green-on-black” was acceptable and furthermore was in keeping with the

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

207

HOST APPLICATION USER INTERFACE REJUVENATION notion of “legacy” access to data center systems. There was also the inevitable issue of cost — with prior rejuvenation schemes invariably requiring some heavy-duty programming effort. This however is now changing, and changing rapidly with corporations across the world beginning to standardize Web pages, within the context of intranets, Internet access, and extranets, as their preferred and strategic means for presenting and soliciting information. “Green-on-black” screens look highly incongruous next to Web pages. Hence, the importance of user interface rejuvenation options vis-à-vis Web-to-host integration products — especially with those offering either Web browser-based (e.g., 3270-to-HTML conversion) or browser-invoked (e.g., Java applet-based emulation) access to mainframe and AS/400 applications. It is also important to note that these rejuvenation options offered by Web browser-oriented host access solutions are significantly easier and less costly to implement than previous solutions. Extensive and compelling user interface rejuvenation options are now available with both 3270/5250-to-HTML conversion and with applet-based, thin-client terminal emulation. Implementations of both of these disparate access schemes now also offer “straight-out-of-the-box” AutoGUI schemes that automatically and “on-the-fly” apply a series of default transformations to “green-on-black” screens to make them more user friendly and modern without the need for any programming, scripting, or even customization. Today, 3270/5250-to-HTML conversion (e.g., Eicon’s Aviva Web-toHost Server or Novell’s HostPublisher) is used more often for rejuvenation than applet schemes, due to two interrelated reasons. The first has to do with its popularity as a true thin-client solution for easily and quickly Internet enabling SNA applications, such those for travel reservations, electronic investing, banking, and parcel/cargo tracking, in order to open them up to for online access by the public over the Internet. The other has to do with fact that most of the HTML conversion solutions offer some type of relatively easy to grasp and straightforward mechanism to facilitate extensive rejuvenation, in addition to built-in AutoGUI capabilities. DIFFERENT LEVELS OF REJUVENATION With 3270/5250-to-HTML conversion, there is always some amount of automatic rejuvenation brought about by the fact that the host screens are now being rendered in HTML, and in addition are being displayed within a browser window, as bona fide Web pages. For a start, the HTML converted output, even if it is still devoid of graphical elements and mainly textual, is unlikely to have the trademark black background of 3270/5250 screens. On the other hand, there is usually no automatic rejuvenation with many applet-based emulation schemes although more and more products are now beginning to offer some type of AutoGUI capability as an option (e.g., IBM’s Host On-Demand). Applet-based emulation, true to its claim of being a bona fide tn3270(E)/tn5250 emulation, tends to still opt for “green-on-black” 208

User Interface Rejuvenation Methodologies with Web-to-Host Solutions emulation windows — displayed alongside Web browser windows. There is, however, some valid justification for this. User interface rejuvenation may not be conducive to certain applications, in particular those that involve high-volume data entry or very high-speed, realtime transaction processing. User interface rejuvenation could slow down and get in the way of such applications. Applet-based 3270/5250 emulation, without rejuvenation, is thus the optimum way to cater to these applications within the context of Web-to-host integration. 3270/5250-to-HTML and the applet-based schemes thus offer, for two very different levels of rejuvenation: 1. Simple default AutoGUI transformations, such as the inclusion of a colored background, substitution of Web page-like input “trenches,” and some screen color re-mapping; these transformations are in effect “screen-neutral” and apply to all the 3270 or 5250 screens of a given application that are using the rejuvenation process, and 2. Application-specific, highly customized facelifts, replete with many graphical and possibly even multimedia elements, akin to the library access screen shown in Exhibit 17-1. The two side-by-side screens in Exhibit 17-2 illustrate the notion of screen content-independent, default transformations achieved with a 3270-to-HTML conversion product. Note that the content and overall appearance of the rejuvenated HTML-based screen is much the same as that of the original screen. This type of minimal intervention and marginal reconstitution is the hallmark and goal of AutoGUI rejuvenation. Note, nonetheless, that the rejuvenated screen, even with this modicum of modernization, is considerably more appealing to the eye and contemporary looking than the original. The bottom of the rejuvenated screen includes a “command” field to compensate for the absence of the toolbar found in the emulator window, as well as a set of buttons and an “action key” input box to emulate 3270 Program Function (PF) key actions. Examples of 3270-to-HTML conversion solutions that offer an AutoGUI capability include Eicon’s Aviva Web-to-Host Server, Novell’s HostPublisher, Attachmate’s HostSurfer for the HostPublishing System (HPS), and Intelligent Environments’ ScreenSurfer. Examples of applet-based, thin-client emulators that now include an AutoGUI function include IBM’s Host On-Demand, OpenConnect’s AutoVista, and WRQ’s Reflection EnterView 2.5. Rejuvenation Options with Applet-Based, Thin-Client Emulators At present, there is really no commonality, consensus, nor market-leading approach, let alone any standards, when it comes to Web-to-host related user interface rejuvenation. This, unfortunately, is unlikely to change in the short to midterm. All of the current rejuvenation techniques are, thus, 209

Exhibit 17-1.

Example of extensive user interface rejuvenation, in this case of 3270 library access application using Eicon’s Aviva Web-to-Host Server 3270to-HTML conversion product.

HOST APPLICATION USER INTERFACE REJUVENATION

210

Exhibit 17-2.

Before and after example of AutoGUI-based rejuvenation with the same library access application as shown in Exhibit 17-1, using Eicon’s Aviva Web-to-Host Server 3270-to-HTML conversion product.

User Interface Rejuvenation Methodologies with Web-to-Host Solutions

211

HOST APPLICATION USER INTERFACE REJUVENATION vendor and product specific — each with their own foibles and nuances. Obviously, they all have to provide mechanisms for realizing the basic operations such as session establishment, screen identification, screen-toscreen and intra-screen navigation, input and output field selection via either a row-and-column position designation, or an indexing (e.g., third field on screen) scheme, and function key management. There are essentially four very different ways to realize complex user interface rejuvenation, as opposed to AutoGUI transformations, with appletbased schemes. These options are: 1. API-oriented schemes: With this approach, there is an API or a Java (or ActiveX) object class library associated with the applet that provides total access to the underlying host access sessions, screens, data fields, and attributes. Java, C++, or Visual Basic (or comparable) development tools are then used with this API or object class library to intercept the host screens and then perform the necessary user interface rejuvenation functions — including that of including data and graphical elements from auxiliary sources. IBM, Eicon, and Attachmate are promoting the Java-oriented Open Host Interface Objects (OHIO) specification as a strategic, object-oriented scheme for this type of rejuvenation — with Eicon’s Aviva for Java V2.0 being the first to offer an implementation of this specification that is likely to become an industry standard. The Javabased Host Access Class Library (HACL) as implemented on IBM’s Host On-Demand applet is another example of this type of API approach. OpenConnect promotes an API known as JHLLAPI, which is a Java version of the HLLAPI API found on traditional emulators. Some products also offer their host access functionality in the form of JavaBeans to facilitate client-side object-oriented software development. 2. Applet-based client: This method relies on an intelligent, customizable, applet-based front-end client that executes on a PC/workstation and performs the transformations necessary to convert the 3270/5250 data stream into a rejuvenated interface, on-the-fly, and without any ongoing assistance from, or intervention by, an intermediary server component. The applet is programmed offline, with the requisite transformations, via a companion design tool — usually referred to as a “design studio.” ResQNet technology (as available with IBM’s Host On-Demand) is an example of this approach. 3. Server-augmented applet: With this approach, an applet, using a heuristic, rules-based scheme, automatically performs many of the 3270/5250 structure-to-GUI element conversions. The applet will typically contain screen images that are roughly 3 Kbytes in size for each screen that has to be rejuvenated. The applet then works in conjunction with a server component that intercepts and preprocesses both 212

User Interface Rejuvenation Methodologies with Web-to-Host Solutions the outbound and inbound data streams. Client/Server Technology’s Jacada for Java is the quintessential example of this approach. (Client/Server Technology recently changed its name to Jacada, Inc.) 4. Integrated Development Environment (IDE): With this approach, a visual, drag-and-drop programming environment à la that associated with Visual Basic is used to extend a host access applet, on an application-specific basis, so that it displays a rejuvenated user interface. This methodology was pioneered by OpenConnect’s OpenVista product. With this approach, all of the rejuvenated screen images that are likely to be used by the application are appended to the applet and downloaded, “in-bloc,” each time the applet is downloaded. All of these rejuvenation techniques, as well as those for 3270/5250-toHTML conversion, provide a mechanism through which the developer can record and capture the screen-by-screen dialog associated with a given application — along with all of the data entry requirements and the navigation through the various screens required to complete a dialog or intercept error conditions. Typically, the developer will have an open and active window that displays, online, the original “green-on-black” 3270/5250 screen(s) being rejuvenated. The rejuvenated interface, with any required graphical and multimedia components such as sound or animation, is formulated within another window. Data fields from the “green-on-black” window can be dragged across or cut-and-pasted into the new window. IBM’s Host On-Demand provides the best-known example of API-based user interface rejuvenation. Host On-Demand offers two separate means for realizing user interface reengineering — in addition to providing a complete set of JavaBeans, with Ver. 3.0 onward, to facilitate programmatic access. The first of these methods is the provision of a Host Access Class Library API that can be used with any Java development tool, as well as with C/C++, Visual Basic, PowerBuilder, and LotusScript, to create a reengineered user interface or realize programmatic access. Other products, such as Eicon’s Aviva for Java V2.0, offer similar Java-centric class libraries (e.g., the Aviva Class Library [ACL]). The second option offered by IBM is the technology from ResQNet.com. ResQNet realizes its integration with Host On-Demand to perform its rejuvenation functions by using the Host Access Class Library API. The Host Access Class Library (HACL) includes a set of classes and methods that provide object-oriented abstractions to perform the following tasks on a tn3270(E) or tn5250 connection with an SNA application: • read a screen image in terms of its 3270/5250 data stream • send input to the application, in a 3270/5250 data stream, as if it was coming from a 3270/5250 screen 213

HOST APPLICATION USER INTERFACE REJUVENATION • specify a specific field relative to a display image through a numerical indexing scheme (e.g., third unprotected field on screen) • read and update the 3270/5250 status line that appears at the bottom of 3270/5250 screens in an area designated as the Operator Information Area (OIA) • transfer files • receive and post notifications, asynchronously (i.e., not in realtime), of designated events such as the arrival of a new screen The OHIO interface, as implemented by Eicon’s Aviva for Java V2.0, can be thought of as being an extended version of HACL, targeted at becoming a vendor-neutral industry standard in the future. ResQNet rejuvenation technology revolves around the premise of dynamic pattern recognition and substitution. In this respect, ResQNet technology bears some resemblance to that available with CST’s Jacada. ResQNet does the bulk of its processing at the client without continual, ongoing assistance of an intermediate server component. To do this, ResQNet relies on an intelligent Java client that is typically 300 to 500 Kbytes in size. Within the context of Host On-Demand, this applet relies on Host On-Demand functionality, accessed via the Host Access Class Library API, to establish communications with an SNA application and to interchange data with it. Extensive customization is achieved using the separately priced Customization Studio and Administrator options of the product. The Administrator capability permits the capture of the screens that are to be further customized by the Customization Studio. Through the Customization Studio, one can rearrange fields, insert graphical images, include check boxes, add new fonts, and perform any kind of text string translation — including translating from one language or character set to another. CST’s Jacada for Java is another popular and powerful applet-based means for realizing user interface reengineering. Much of the user interface conversions performed by Jacada revolve around a potent, rules-based system known as CST KnowledgeBase. CST claims that KnowledgeBase, at present, contains over 700, 3270/5250-centric pattern definitions that permit the dynamic recognition of oft-found 3270/5250 screen “elements” — for example the “F8-Forward,” “F7-Backward,” and “F3-Exit” PF-key definition designations that invariably litter the bottom of most 3270/5250 applications. Each pattern definition included in the KnowledgeBase has a substitution string that may involve graphical elements associated with it. The conversions specified in the KnowledgeBase can be automatically applied in offline mode to an application’s screens through CST’s Jacada Automated Conversion Environment (ACE). The Java applet that will render and manage the rejuvenated interface, as well as host communications, albeit with ongoing support from a Jacada Server, will be generated by ACE without the need for developer intervention. There is a facility whereby the 214

User Interface Rejuvenation Methodologies with Web-to-Host Solutions conversions specified within the KnowledgeBase can be overridden, for a particular rejuvenation process, by ACE. Extensive customization is also possible using ACE, where a developer, aided by easy-to-follow “wizards,” can capture, online, the screens that need to be reengineered and then perform the necessary conversions using a combination of the transformations included in the KnowledgeBase and bespoke alterations. The average size of a Jacada Java applet required to render a typical rejuvenated screen is around 3 Kbytes. Often-used Java classes and screen layouts can be cached on a PC’s hard drive or RAM memory to minimize the amount of data that has to be downloaded from the Jacada server. With OpenVista’s IDE approach, the IDE, following drag-and-drop instructions from a developer, will generate the Java code to create a single applet that will display and handle the new rejuvenated interface — along with all of the underlying tn3270(E)-oriented interactions necessary to communicate with the host application. With the OpenVista approach, rejuvenation-related transformations are not done on-the-fly by the applet, at the client, as it receives the 3270/5250 data stream from the application. Instead, the required transformations are designed into the applet. If so desired, a Java applet produced by OpenVista can be modified, augmented, or refined using any of the popular Java development tools. There is even an OpenVista-provided API to facilitate quick access into the Java classes that appear in the applet. The finished applet is then stored at the appropriate Web server so that it can be dynamically downloaded to a browser — and, where applicable, cached on a PC/workstation hard drive. Rejuvenation Options with 3270/5250-to-HTML Conversion 3270/5250-to-HTML conversion products typically offer two different techniques for facilitating user interface rejuvenation. These options are: 1. Scripting: With this approach, a script-based mechanism that either leverages popular scripting schemes (such as JavaScript) or is vendor specific and proprietary is used to reengineer the user interface. Novell’s HostPublisher, for example, allocates three HTML templates to each application — one template for the data transporting LU-LU session, another for the SSCP-LU control session, and the third for the bitmap Web page that is used to support light pen and cursor positioning operations. The template associated with the LU-LU session can be customized, typically with a JavaScript, to provide a set of conversions that apply to all the 3270 screens displayed by that application. 2. API-based rejuvenation: With this approach, just like with its counterpart via-à-vis applet-based emulators, one or more APIs are provided to enable developers to easily access the output being produced by the HTML conversion process. These APIs can be 215

HOST APPLICATION USER INTERFACE REJUVENATION accessed from programming language such as C, C++, Visual Basic, Visual J++, or Microsoft’s new Visual InterDev. Scripting is typically the easiest, most expeditious, and consequently a highly popular way to realize interface reengineering with 3270/5250-to-HTML. Scripts enable dynamic content to be added to Web pages. The scripting scheme may be client centric or server centric. Both schemes enable the browser image seen by the user to be made up of intermingled HTML code, scripting code, Java applet code, as well as objects such as Enterprise JavaBeans. With the client-centric approach, the script code, for example JavaScript code, necessary to handle the new presentation elements is embedded within the HTML page representing one or more 3270 screens. This code then gets downloaded to the client PC/workstation along with the rest of the Web page. The code will execute on the client, typically within the Java Virtual Machine within the browser, to handle various components of the new interface. Most of the server-centric approaches, such as that offered by Eicon’s Aviva Web-to-Host Server, revolve around Microsoft’s Active Server Page (ASP) methodology for browser-neutral, server-based scripting. Support for ASP-based scripting came to be with Microsoft’s Windows NT-based Internet Information Server (IIS) 3.0 Web server. ASP is now also supported by Microsoft Peer Web Services Version 3.0 on Windows NT Workstation and Microsoft Personal Web Server on Windows 95/98. ASP permits the creation of dynamic, highly interactive, high-performance Web server applications. ASP works with any ActiveX scripting language and has integrated support for VBScript, JScript, and InterDev Support for other popular scripting languages such as IBM’s REXX and Perl (Practical Extraction and Report Language) is available via widely available plug-ins from third parties. ASP, in addition, permits multiple scripting languages to be used interchangeably to create a single Web server application. ASP relies on “scripting engines” developed using Microsoft’s Component Object Model (COM) architecture to process scripts. Irrespective of the scripting scheme used, the output of an ASP application is always HTML. It is thus ideally suited for creating and manipulating HTML within the context of interface reengineering based on 3270/5250-to-HTML conversion. ASP, at least at present, can only be used with Microsoft Web servers. To support other Web servers, most vendors that offer ASP-based interface rejuvenation typically also offer a non-ASP scheme. Attachmate, for example, provides a Visual Basic-to-HTML capability in addition to its ASP support. Interface rejuvenation via an API as supported by many of the 3270/5250to-HTML products is in essence a logical equivalent of the HLLAPI and EHLLAPI interfaces that have been universally available with all major 3270/5250 fat-client emulators and tn3270(E) clients for many years — for the development of so-called “screen-scraping”-based client applications. 216

User Interface Rejuvenation Methodologies with Web-to-Host Solutions Screen-scraping refers to the notion of dynamically capturing, via the API, what would be the 3270/5250 screen images displayed by an SNA application by intercepting and interpreting the data streams transmitted by that application. Screen-scraping, which is performed at the client, permits the content of the 3270/5250 data stream to be used as input to a client-resident application driving a GUI or performing a different business task to that of the SNA application whose screens are being scraped. 3270/5250-to-HTML is in reality also a screen-scraping technique — albeit server, as opposed to client based and HTML centric. The APIs, which can typically be invoked from any contemporary programming language, permit a server component to be developed which talks 3270/5250 on the host side, and generates HTML on the Web server side. To be fair, this API approach, which is obviously highly flexible and extensible but at the same time significantly more involved than scripting, is better suited for developing sophisticated new applications that extract data from SNA applications, than for just realizing user interface rejuvenation. The exact machinations involved in reengineering a user interface via an API-based scheme, as is to be expected, are product as well as application language specific. BOTTOM LINE The bottom line when it comes to Web-to-host related user-interface rejuvenation is that there is plenty of choice, whether it be for the 3270-toHTML conversion solutions or the applet-based emulation approaches, spanning the entire spectrum of possibilities ranging from out-of-the-box AutoGUI schemes to those involving bona fide Java applet programming with a tool such as Visual Café or Microsoft’s InterDev. The key frustration is the lack of any commonality among the approaches advocated by the market-leading vendors, although OHIO may eventually become an industry standard. With scripting schemes for 3270/5250-to-HTML conversion, ASP, although server specific, is highly popular and widely used to the extent that it can be viewed as a de facto standard. With all of the options now readily available, including the powerful and compelling AutoGUI schemes, there is really no excuse for not rejuvenating the dated and hostile user interfaces of mainframe and AS/400 applications.

217

Section IV

Host Integration and Application Servers IN THE DAYS OF CLIENT/SERVER COMPUTING, THE NOTION OF THREE-TIER (or n-tier) computing became commonplace. In this paradigm, there is a client and a server that communicate with one another. But between these two entities may be one or more other servers that add value, do some preprocessing, combine results from multiple servers into a single user transaction, etc. In the world of Web-to-host integration, these new platforms are host integration servers and application servers. Chapter 18 includes a detailed description of an application server, while Chapter 19 describes the more specific duties of a host integration server. Microsoft's Babylon, an example of one host integration server, is described in detail in Chapter 20.

219

Chapter 18

Application Servers: The Next Wave in Corporate Intranets and Internet Access Lisa M. Lindgren

A CORPORATION’S WEB PRESENCE TYPICALLY EVOLVES IN THREE STAGES. In the first stage, static information is published via Web pages. Information about the company, its products, and its services is made available to the general public via the Internet. In a more secure internal intranet, employees have access to company holiday schedules, personnel policies, company benefits, and employee directories. While this first step is necessary, it is really only a substitute for other traditional forms of publishing information. The information can become dated, and there is no interaction with the user. Most organizations quickly evolve from the first step to the second — publishing dynamic information and dynamically interacting with the user via new scripts, applications, or applets that are written for the Web server or Web client. An example of this stage of Web presence is a newspaper that offers online news content and classified ad search capabilities. This stage offers real-time information, rather than static “brochure-ware,” and presents the opportunity to carry out electronic commerce transactions. The second stage usually demonstrates to an organization the vast efficiencies and increased customer and employee satisfaction that can result from a well-designed and executed intranet and Internet presence. The challenge many organizations then face is how to rapidly deliver new services over their corporate intranets and the Internet. In the third stage of Web evolution, the focus is on offering new transactional services that communicate directly with the core IT systems. This allows companies to maintain a competitive edge and meet the unslaked 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

221

HOST INTEGRATION AND APPLICATION SERVERS thirst for new and better ways to interact with an organization via the familiar Web interface. The transactional services are offered over the Internet for public use, over business-to-business extranets to allow business partners to more effectively do business, and over internal corporate intranets to offer employees new and better ways to do their jobs. Examples of this third stage of Web presence geared to the public over the Internet include home banking, package tracking, travel booking, stock trading, and the online purchase of consumer goods. Business-to-business examples include online policy sales and updates for insurance agents, manufacturing and delivery schedules for distributors, and direct order entry into suppliers. Intranet examples geared to employees include expense report submission, benefits calculation, and conference room scheduling. The key emphasis of this third stage of Web presence is its transactional nature. This next level of services can only be achieved by tapping the vast and sophisticated systems and applications that have been built over a period of years. These mission-critical systems and applications represent the “crown jewels” of an IT organization, and include customer records, product availability and pricing, customer service databases, and the transactional applications that literally keep the business running. IT organizations must try to create a unified interface, leveraging a variety of existing systems. The problem is that the existing systems are usually very diverse. They differ in architecture (i.e., client/server versus hierarchical), operating system, programming language, networking protocol, interface (i.e., real-time, batch, programmatic), and access control. The application server is a new breed of product that unifies a variety of different systems and technologies in order to deliver new transactional services to a variety of clients. OVERVIEW OF A WEB SERVER To fully understand what an application server does, it is first useful to review the functions of a Web server. A Web server’s primary function is to “serve” Web pages to Web clients. The protocol used between the Web client and the Web server is HyperText Transfer Protocol (HTTP). HTTP defines the valid operations between the Web server and the browser. For example, the Get operation is how the browser requests the download of a particular Web page or file. Exhibit 18-1 illustrates the sequence of events when a Web client requests the download of a particular Web page. HyperText Markup Language (HTML) defines the contents and structure of the Web page. It is the browser, not the server, that reads and interprets the tags within HTML to format and display a Web page. Extensible Markup Language (XML) is the next-generation Web page content language that allows programmers to define the tags in a page for better programmatic access to the page content. XML separates the definition of content from the presentation of that content. 222

Application Servers: The Next Wave in Corporate Intranets and Internet Access

Exhibit 18-1.

Sequence for download of a Web page.

The Web page can contain text, images, video, and audio. The Web server serves up the files associated with these different types of content the same. It is the Web browser that must display or play the different data types. As long as the request from the Web browser is valid, the file type is known, and the file exists, the Web server simply downloads whatever is requested.1 The server behaves differently, however, if the page that the Web browser requests is actually a script. A script, quite simply, is a program. It can be written in any language and can be compiled or interpreted. A script can be used to access non-Web resources such as databases, to interact with the user via forms, and to construct documents dynamically that are specific to that user or that transaction. The Web server executes the script and the results are returned to the user in the form of a Web page. Scripts interface to the Web server using either a standard or a vendor-proprietary application programming interface, or API2. The base standard API is the Common Gateway Interface (CGI). Some Web server vendors offer proprietary APIs that extend the capability beyond what is possible with CGI. For example, Netscape and Microsoft both defined proprietary extensions in their products (NSAPI and ISAPI, respectively). Microsoft’s Active Server Pages (ASP) technology is an alternative scripting technology for Microsoft Web servers. A Web server, then, serves Web pages to users but also executes business logic in the form of scripts. The scripts can gather data from databases and applications on various systems. The result is returned to a single type of user, the Web browser user. OVERVIEW OF AN APPLICATION SERVER An application server is an extension of a Web server running scripts. Like Web servers, application servers execute business logic. The scripts that execute on a Web server can be written to integrate data from other systems, but there are no special tools provided with the Web server to do so. In contrast, this integration of other systems is a key focus and integral 223

HOST INTEGRATION AND APPLICATION SERVERS part of the application server. It includes a set of “back ends” that handle the job of communicating with, extracting data from, and carrying out transactions with a wide variety of legacy applications and databases. And while a Web server only accommodates a single type of user, an application server can deal with several types of end users, including Web browsers, traditional desktop applications, or new handheld devices. Some application servers are sold bundled with a Web server. Others are sold independently of a Web server and will communicate with a variety of different Web servers running on the same physical server or across the network to a Web server on a different machine. However, most application servers can function without a Web server. An IT organization could implement an application server that only communicates with in-house PCs over an internal network without using Web servers or Web browsers at all. Nonetheless, the strength of the application server, compared to other types of middleware, is its ability to form a bridge between the existing legacy applications (including traditional client/server applications) and the new, Web-based applications driving what IBM calls “E-business.” Exhibit 18-2 depicts the basic architecture of an application server. At the core of the application server is the engine that ties all of the other pieces together and sets the stage for application integration. In many application servers, this engine is based on an object-oriented, component-based model like the Common Object Request Broker Architecture (CORBA), Enterprise Java Beans (EJB), or Microsoft’s (Distributed) Component Object Model (COM/DCOM). Each of these architectures supports the development, deployment, execution, and management of new, distributed applications.

Exhibit 18-2.

224

Basic architecture of an application server.

Application Servers: The Next Wave in Corporate Intranets and Internet Access • CORBA: Defined over a period of years by the Object Management Group (OMG), a vendor consortium of approximately 800 members, CORBA is a component framework that is language-neutral and supported on a wide variety of platforms. At the heart of the CORBA framework is the Object Request Broker (ORB). Communication between objects is achieved with the Internet Inter-ORB Protocol (IIOP). • Enterprise Java Beans: EJB is a Java-based component framework defined by Sun Microsystems. Once potentially at conflict with CORBA, the two frameworks have begun to complement one another. The EJB specification defined the Remote Method Invocation (RMI) as the method for components to communicate across Java Virtual Machine (JVM) and machine boundaries. RMI-over-IIOP is becoming common as the two frameworks begin to more explicitly support one another. • COM/DCOM: The vendor community positions COM/DCOM as yet another Microsoft proprietary architecture meant to lock customers in to Microsoft-specific solutions. Microsoft positions it as the most widely implemented component model because COM/DCOM has been an integral part of all Windows systems since the introduction of Windows 95. A number of UNIX system vendors have indicated they will support COM in the future. The definition of standards and architecture for creating stand-alone components, or objects, allows application developers to combine previously developed components in new ways to create new applications. The developer is then able to focus on the business logic of the problem at hand rather than the details of the objects. With the combination of object technologies and the new visual development tools, new applications are more easily built and more stable than the monolithic, built-from-theground-up applications of the past. It is because of this flexibility that most application servers are based on a core component-based engine. Application servers offer “back ends” that provide an interface into data and applications on other systems. These back ends are often called connectors, bridges, or integration modules by the vendors. These connectors can interact with an application or system in a variety of different ways and at a variety of different levels. The following connectors are available on some or all of the commercially available application servers: • Web server interfaces • message queuing interfaces for Microsoft’s MSMQ and IBM’s MQSeries • transactional and API interfaces to the IBM CICS or the Microsoft Transaction Server (MTS) • structured query database interfaces (e.g., SQL, ODBC, DRDA) • component connectors to Java applets and servlets, ActiveX components, CORBA objects, Enterprise Java Beans, and others

225

HOST INTEGRATION AND APPLICATION SERVERS • terminal interfaces to legacy applications on mainframes and midrange systems (e.g., 3270, 5250, VT220, HP, Bull) • application-specific interfaces to Enterprise Resource Planning (ERP) applications, such as those from SAP, PeopleSoft, and Baan • custom connectors for custom applications Downstream from the application server to the client, the protocol can vary, depending on the type of client and the base technology of the application (i.e., CORBA, EJB, COM). A common and basic method of exchanging information with end users will be via standard Web pages using HTTP, HTML, and possibly XML. Another option that involves some local processing on the part of the client is to download Java or ActiveX applets to the client. This thin-client approach is desirable when some local processing is desired but the size of the client program is sufficiently small to make downloading over the network feasible. When a more traditional fat-client approach is required, in which the end user’s PC takes on a larger piece of the overall distributed application, a client-side program written in Java, C, C++, or any other language is installed. In this case, the client and the application server will utilize some communication protocol, typically over TCP/IP. In the case of CORBA, the standard IIOP is used. In Java environments, the standard scheme is Remote Method Invocation (RMI). Microsoft’s COM/DCOM specifies its own protocol and distributed processing scheme. Exhibit 18-3 illustrates an example of an enterprise that has application servers, multiple back ends, and multiple client types. A final but important piece of the application server offering is the support for visual development tools and application programming interfaces (APIs). Because application servers are focused on building new applications that integrate various other systems, the ease with which these new applications are developed is key to the viability and success of the application server. Some application servers are packaged with their own integrated development environment (IDE), complete with a software development kit (SDK), that is modeled after the popular visual development tools. Other vendors simply choose to support the dominant visual development tools, such as the IBM VisualAge, Microsoft’s InterDev, or Symantec’s Visual Café. The number of application servers available on the market grows each day. Vendors offering these products come from a wide variety of backgrounds. Some have a solid background in providing client/server integration middleware; others were early adopters of standards-based component technology like CORBA; and still others have evolved from the Web server space. Exhibit 18-4 lists some of the application servers available, along with some of the key points of each of the products.

226

Application Servers: The Next Wave in Corporate Intranets and Internet Access

Exhibit 18-3.

Example of an enterprise with application servers.

DEPLOYMENT IN THE ENTERPRISE When deploying application servers in an enterprise environment, there are some very important and key capabilities of the application server that must be considered above and beyond its component architecture, protocols, and back ends. IT organizations that have made it through the first two steps of Web integration and Web presence and are now ready to embark on this third phase realize how quickly Web-based systems become mission critical. Once new services like online catalog ordering, home banking, Web-based trading, and others become available, new users rapidly adopt the services and become reliant on them. If the Web-based systems of a company fail, consumers are likely to go elsewhere and never return. Therefore, it is essential that the application servers be designed and implemented with ample security, scalability, load balancing, fault tolerance, and sophisticated management capabilities. SECURITY Security is even more critical in an application server environment than in a stand-alone Web server environment. This is because an integral part 227

HOST INTEGRATION AND APPLICATION SERVERS Exhibit 18-4. Application servers available. Vendor

Product

BEA

WebLogic

Bluestone Software

Sapphire/Web

IBM

Inprise

WebSphere Application Server Enterprise Edition Application Server

Microsoft

Babylon (avail. 2000)

Novera

Integrator

Key Points Family of products offering different levels; based on Java but CORBA support comes in at the high end; built on common base of the BEA TUXEDO transaction monitor; includes support for Microsoft’s COM Java-based solution; includes integrated development environment for application development; large number of integration modules for back-end access to systems; state management and load balancing Includes Web server; focused on high-volume transactions and high reliability; core technologies are CORBA, EJB, XML; common IIOP infrastructure Built upon Inprise’s VisiBroker, a dominant ORB in the CORBA market space; integrated solution with Web server, IDE (Jbuilder), and management (AppCenter) Successor to Microsoft’s SNA Server; built around Microsoft’s COM/DCOM model; integration of UNIX, NetWare, and IBM mainframe and midrange systems; COMTI integrates transaction systems; includes direct access to mainframe/mid-range data, DRDA for IBM database access, and MQSeries bridge Integrator includes the component designer back ends with Novera’s Integration Server, the runtime environment; Integration Server runs in a Java Virtual Machine; communication to objects and other servers is based on the CORBA IIOP

of the application server is the integration of existing data and applications. Often, these data and applications reside on mission-critical systems like IBM mainframes and midrange systems and high-end UNIX platforms. These are the systems that house the most important and sensitive information in an enterprise, including customer records, historical sales information, and other material that would be valuable to the competition or to the malicious hacker. An overall security plan and architecture must accomplish three things. First, it must ensure that the data flowing in the network and on the wire is not legible to prying eyes. Second, it must ensure that the identity of the user is verified. Third, it must ensure that a particular user can only access the resources for which he or she is authorized. A number of different technologies and products can be leveraged to accomplish these three goals. For example, Secure Sockets Layer (SSL) is a popular security protocol that accomplishes the first two goals by using 228

Application Servers: The Next Wave in Corporate Intranets and Internet Access encryption on the wire and digital certificates for user authentication. Secure HTTP (HTTPS) is also used to protect Web transactions. Applicationspecific user ID/password schemes as well as centralized servers, such as those based on the Lightweight Directory Access Protocol (LDAP) standard, provide user authorization. Application servers must also take into account the notion of session persistence as a facet of security. There is a fundamental mismatch between the Web paradigm of user-to-server interaction when compared to client/server or traditional hierarchical applications. In the Web paradigm, each individual page interaction or request is a stand-alone transaction. The Web server does not maintain state information for each user. Session state information must be maintained by an application server to prevent the possibility of one user gaining access to an existing, active session. This is a security issue because, without session persistence, user authentication and user authorization security schemes are compromised. SCALABILITY, LOAD BALANCING, AND FAULT TOLERANCE Scalability refers to the ability of a system to grow seamlessly to support an increasing number of users. Systems that are scalable are able to add users in such a way that the consumption of resources is linear. The system should not hit a bottleneck point or barrier beyond which the addition of another user dramatically impacts session resources or overall response time. Systems that are scalable can grow to accommodate a particular maximum number of concurrent users in such a way that the response time is roughly equivalent for all users. For many organizations, the design point for scalability will be thousands — or even tens of thousands — of concurrent users. This level of scalability is usually only achieved by implementing multiple, load-balancing servers. In this design, there are multiple application servers, each supporting the same services and presenting a portion of the total pool of available servers. End users, either fat-client PCs or thin-client Web-based users, should all have a common view to the pool of application servers. That is, one should not have to configure each device or session to use a specific server in the pool. The load-balancing front end (which may be a separate unit or integrated into the application server) should load-balance sessions across all available servers in an intelligent manner based on system capacity, current load, and other metrics. High availability is provided by the load-balancing front end through its awareness of the availability of the application servers. If a server fails, it obviously should be removed from the pool of servers to which new sessions are allocated. Existing sessions that are active at the time of the failure of an application server will usually be disrupted, although some systems, like the IBM mainframes with Parallel Sysplex, can avoid even session disruption. 229

HOST INTEGRATION AND APPLICATION SERVERS MANAGEMENT Because an application server environment encompasses a variety of different types of users, back ends, and distributed processing technologies, it can be a very complex environment to manage. Most application server vendors provide tools that are supported using one or more of the common management platforms, including IBM TME 10/NetView, CA UniCenter, and HP OpenView. The management tool should include the ability to manage the pool of application servers as a logical entity. The operator should be able to view and control all of the resources, objects, and sessions from an application viewpoint. A visual display of all elements with current status should be an integral capability. The management tool should be able to assist with the deployment and tracking of new applets and applications. The ability to specify actions based on certain events can help to automate some of the routine management functions. Additional information for capacity planning and modeling is helpful. CONCLUSION Application servers allow organizations to evolve to the third phase of Web presence, in which the focus is on providing real-time transactionbased services to both internal and external users. The integration of the wealth of existing data processing systems, applications, and data is essential to the ability to deliver new transactional services quickly and efficiently. Application servers unify the existing systems with the Web-based infrastructure, allowing IT organizations to leverage their vast investment in systems and applications to deliver new services to their employees, business partners, and the public. Notes 1. Yeager, N. J. and McGrath, R. E., Web Server Technology: The Advanced Guide for the World Wide Web Information Providers, Morgan Kaufmann Publishers, Inc., pp. 37–41. 2. Ibid., pp. 58–59.

230

Chapter 19

Host Integration Servers Lisa M. Lindgren

RESEARCH FIRMS AND EXPERTS ESTIMATE THAT APPROXIMATELY 70 PERCENT of mission-critical data still reside on “legacy” computing systems today. By legacy system, the experts are referring to traditional data-processing platforms typically found in data centers and maintained, around-theclock, by IT staff. These systems are IBM-style mainframes, IBM midrange systems, and other platforms sold by a variety of vendors (DEC, HP, Bull, Unisys, etc.) that support mission-critical applications. One of the outcomes of the client/server computing revolution was going to be the elimination of these expensive, proprietary, dated platforms and replacement by a new generation of low-cost servers based on industry standards or de facto standards. Client/server never achieved this lofty promise. In large part, this failure was due to the lack of a solid business case for porting the legacy applications to new platforms. The legacy platforms provided fault tolerance and 24/7 operation that were unavailable on new servers. In addition, the cost of the legacy platforms began to fall and the platforms became much more adept at supporting the new open technologies. The cost of the IBM mainframe in terms of dollars per MIP, for example, has fallen drastically in the past decade and the standard mainframe operating system now includes support for TCP/IP as a nocharge feature. The applications and the data that still reside on the legacy platforms are truly the lifeblood of many enterprises. This is where the customer records, billing, manufacturing resource planning, and other critical systems are located. The major issue facing IT organizations today is tapping that data and those applications to build new E-commerce capabilities that allow more efficient communication with trading partners and end customers. Many legacy applications are built on a character-based interface that assumes that an end user is communicating to it through a display terminal or software emulating a display terminal. In these applications, the business logic is intertwined and interconnected with the user interface. One 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

231

HOST INTEGRATION AND APPLICATION SERVERS cannot access the data that is a part of the application (e.g., the customer billing data) without stepping through the transaction-oriented terminal interface. Some legacy applications, however, are batch or programmatic rather than transaction based. The applications are program-to-program, with an “intelligent” client or server communicating with the legacy host. A prime example of this type of interaction is a middle-tier relational database server that supports a newer, client/server-based program that queries data from a legacy mainframe database. Some large enterprises will have a wide variety of different types of legacy applications, each with its own unique interface. A host integration server is a relatively new category of products that will allow organizations building a Web-to-host environment to easily tap a variety of types of legacy applications without requiring any change to the legacy applications. It differs from other types of Web-to-host solutions in that it is a server-centric solution that is focused on integrating host data into Web-style applications rather than providing a general-purpose platform and toolkit for Web application development and deployment. THIN CLIENTS VERSUS SERVER-CENTRIC SOLUTIONS The Web-to-host market began in 1996 with a few products that were geared to providing access from a Web browser to an IBM mainframe. Early on, there were two camps as to how that access should be provided and therefore two very different types of products. The two basic product types were thin-client emulator applets and server-centric Web-to-host gateways. Before Web-to-host solutions, users who wanted to access legacy applications usually installed special-purpose terminal emulation software on their desktop PCs. As the name implies, this software emulates the functions of a fixed-function display terminal that provides character-based access to transactional applications on legacy systems. Like so many other PC applications, the emulator software grew in size over time, and enterprise IT staffs spend a lot of money and effort performing the desktop software distribution and maintenance tasks for these emulators. The thin-client approach to Web-to-host access is based on the premise that these traditional “fat-client” emulators can be replaced with thinner equivalents. Java and ActiveX, Web-oriented technologies that allow for the dynamic download of client software, were the key to eliminating the software distribution and maintenance tasks associated with traditional client-based software. Initially, the thin-client Web-to-host products simply replaced the functions of the fat-client emulator and continued to provide the same “green-on-black” user interface common to the emulator environment. Over time, however, thin-client Web-to-host products have grown in sophistication. Now, many leading solutions provide one or more means of 232

Host Integration Servers rejuvenating the user interface so that thin-client solutions can provide users with a more pleasing, Web-style interface. The commonality of the thinclient solutions is that an applet is downloaded from a Web server to the client. It is the applet that contains the logic that allows the client to connect to and establish a session with the host. The second camp for early Web-to-host solutions was established based on the premise that the client software should have a “zero footprint.” In other words, all host access processing should be performed on a middletier “gateway” server and the client should only be required to have a standard Web browser. The communication between the client and this host access server is performed only with standard HTML. It is the server that is responsible for containing the logic to connect to and establish a session with the host. Early forms of the server-centric products were 3270-toHTML converters. This class of server-centric product provides on-the-fly conversion between the standard data stream utilized by IBM mainframes (the 3270 data stream) and HTML. The host and the application are not changed, and the client simply needs a browser. Because the 3270 data stream is converted to HTML, there is automatically some level of rejuvenation of the user interface inherent in these products, even if that rejuvenation simply provides a pleasing background, radio buttons for PF key assignments, and other simple enhancements of the user interface. Initially, the vendors providing these different solutions each claimed that their approaches were suitable for two very different types of audiences: 1. Intranet/extranet users: These users are the traditional users of terminal emulator fat-client software. They typically require regular access to one or more legacy applications, perhaps as a major part of their job. Internal to the organization, these may be data entry or customer service representatives who need to access customer records, billing applications, etc. Extranet users may be dealers or distributors who need access to order entry and order status information. To these users, Web-to-host solutions are a replacement for their current host access solution. 2. Internet users: These are users who have never before seen or interacted directly with the legacy applications. Examples include consumers doing home banking, Internet-based shopping, and package tracking. Business-to-business examples may include insurance agents who used to have to call in to an insurance company’s call center and now gain direct pricing and policy information over the Internet. Web-to-host solutions provide an extension of the traditional legacy host-access user base. However, the needs of these very different user bases are quite different, as is the way in which they access the legacy systems. Intranet/extranet users often require many of the features and functions of the traditional 233

HOST INTEGRATION AND APPLICATION SERVERS emulator because they have built up training, scripts, and tools over the years to accomplish the host access task more efficiently. These users typically have a need to communicate with the host more consistently throughout the workday. And to some of these users (e.g., data entry workers), rejuvenating the application will only impede productivity rather than enhance it. Internet-based users, on the other hand, typically only require a simple, single transaction with the host application. These users do not want to learn how to navigate the legacy application, and therefore rejuvenation of the user interface is a must. These users also count speed and responsiveness as a key requirement. Therefore, the time to download even a thin-client applet may diminish the appeal of an applet-based solution. Because of these differences, the market has more or less naturally segmented itself by user base. The thin-client solutions are more appropriate to the fat-client replacement market, while server-centric solutions are better suited to the extension market, in which new users access the host application. Many vendors now accept and embrace this market segmentation, and offer a family of products that include both thin-client and server-centric solutions. The balance of this chapter focuses on server-centric solutions in general, and more specifically focuses on the class of server-centric solutions known as host integration servers. HOST INTEGRATION SERVERS A host integration server is a server-centric Web-to-host integration solution that has the following characteristics. • It runs on either a middle-tier server or the destination-host server and may support one or more different server operating systems, including perhaps NT, UNIX, NetWare, OS/390, OS/400, or Linux. • It supports “zero-footprint” clients, sending standard HTML (and perhaps XML) to the clients. • It communicates upstream with a variety of legacy host applications through a variety of transaction, batch, and programmatic interfaces (e.g., 3270 data stream, 5250 data stream, VT, ODBC/JDBC, MQSeries, CICS API(s)). • It includes the means to utilize a visual development tool to easily integrate the host data and applications into new Web pages; it may or may not provide on-the-fly conversion for host data streams. • It may include security, scalability, and fault tolerance features such as SSL, load balancing, and hot server standby. • It interoperates with Web servers and possibly with new application servers. By this definition, 3270-to-HTML conversion products are very basic host integration servers that only support a single type of host application 234

Host Integration Servers interface — the 3270 data stream (which, granted, has the largest installed base and therefore the largest target market). The 3270-to-HTML converter products almost always provide on-the-fly conversion capability, allowing these products to be installed and up and running with no programming, scripting, or customization. Modern host integration servers offer much more capability than basic 3270-to-HTML converters. One obvious and apparent difference is in the support for different types of host applications and different data sources. With a host integration server, one can build Web pages that integrate data from a variety of different legacy host applications. For example, a home banking Web page may include the customer’s name and address from a mainframe CICS application, current account activity from a Sybase database located on a Tandem system, and special promotions that the customer may take advantage of from an AS/400 back-office system. By contrast, a 3270-to-HTML converter can only communicate with mainframe applications that support the 3270 data stream. Another difference between the early 3270-to-HTML products and true host integration servers is in the assumed amount of scripting and customization. Modern host integration servers presume that the new user interface will not simply be a one-to-one correlation between host screen and HTML-based Web page. Therefore, host integration servers are focused on providing customization studios (or interfaces to standard customization studios) that allow programmers to easily design brand new Web-style interfaces that incorporate host data. On the other hand, 3270-to-HTML products are geared to providing quick and easy access to host applications with some level of rejuvenation. The on-the-fly conversion capability is usually counted on to do the majority of the user interface rejuvenation. Most 3270-to-HTML converters also support some level of scripting or programming to allow more sophisticated rejuvenation, but the simplicity of the on-the-fly conversion is the real selling point of these products. So, with its sophisticated user interface redesign capabilities, how does a host integration server compare to a new application server? Application servers have many of the characteristics listed above for host integration servers. The major differences between the two are that the application server: • is targeted to the development of new business logic rather than the access of existing legacy business logic • is built upon an object-oriented base, supporting some combination of CORBA, Enterprise JavaBeans, and Microsoft’s DCOM • contains connectors to legacy data and applications, but the list may not be as complete as those provided with host integration servers An application server (or Web application server) is a platform for the development of new applications. Therefore, host integration servers and 235

HOST INTEGRATION AND APPLICATION SERVERS Exhibit 19-1. Host Integration Servers. Vendor

Product Name

IBM

HostPublisher

InfoSpinner

ForeSite Application Server

Microsoft

Babylon (code name)

WRQ

Apptrieve

Key Points Written in Java and supported on NT, UNIX, OS/390; comes bundled with IBM WebSphere (Web application server platform); multiple legacy data sources (3270, 5250, VT, Java, databases); includes SSL and DES for security and load balancing and hot standby with Network Dispatcher; includes HostPublisher Studio for user interface design NT-based solution; co-resides with Web Server and interfaces via CGI, NSAPI, ISAPI; supports a variety of data sources (3270, 5250, DB2, ODBC, Java, ActiveX); includes Integrator component which allows development of HTML templates for user interface design Windows 2000 only; follow-on to Microsoft SNA Server gateway; based on Microsoft’s COM/DCOM object model; supports a variety of IBM mainframe and AS/400 sources as well as UNIX and NetWare NT or Solaris support; supports terminal-oriented and database (JDBC) legacy applications; design tool builds an object that represents how the host data is accessed; standard integrated development environment tools then integrate these objects

application servers are complementary products rather than competing products, particularly if they can communicate and share data. For example, a host integration server may create objects containing legacy application access that can be utilized by an application server. Host integration servers are the new generation of server-centric products and are focused on integrating the wide variety of legacy applications with the new Web environment. Exhibit 19-1 offers a list of some commercially available host integration servers, along with some of the salient points about the product. A GOOD FIT FOR HOST INTEGRATION SERVERS With the plethora of different types of solutions available for providing legacy host system access from Web browsers, it is important for enterprise IT staffs to select only those solutions most appropriate to their specific environments. Host integration servers comprise a relatively new category of product that can solve some specific needs better than other types of solutions. An enterprise organization that has most or all of the following characteristics should evaluate host integration servers. • The organization needs to extend current legacy host access to new users who have no experience with the legacy systems. 236

Host Integration Servers • The IT department cannot control or dictate the level of browser or type of operating system that the user is running. • Users need to access data and applications from a variety of different types of host systems. • It is desirable to redesign the way in which users interact with the legacy host, so there is no longer a one-to-one correlation between host screen and Web page. • The organization will move to application servers for new business logic in the future but is not yet ready to deploy this object-oriented framework right now. • Fault tolerance, security, and scalability are important factors. An organization whose users are mostly internal users or business partners who are already familiar with the legacy systems may actually find that thin-client solutions are a better fit than host integration solutions, since the thin-client applets are a more complete replacement for existing desktops. An organization that is more interested in deploying new business logic, with some integration of legacy host data, may find that a fullblown application server (many of which include connectors for legacy data) should be the first step. However, the relatively large number of organizations that fit the characteristics described above are ripe for a hostintegration server solution. CONCLUSION Research indicates that 70 percent of mission-critical data still resides on legacy host systems. However, the applications that reside on these systems are varied. Early Web-to-host solutions focused on supporting certain types of hosts and certain types of application interfaces. Early solutions also tried to meet the needs of both “expert” host system users and a new population of casual users. The host integration server is a new category of server-centric solution that excels at allowing IT organizations to build a new interface into a broad base of existing legacy applications. This category of product is a natural fit for organizations that need to extend the vast data locked up in their varied, mission-critical legacy systems to a new population of end users. The host integration server is also a complementary solution to the full-blown application server, which is the modern platform for the development and deployment of new business logic based on object-oriented models.

237

Chapter 20

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise Anura Gurugé

THE INTEROPERABILITY OF WINDOWS 2000 WITH IBM (AND COMPATIBLE) mainframes, AS/400s, UNIX systems, and Novell NetWare environments is addressed by a set of Microsoft-developed features currently code-named “Babylon.” This interoperability with non-Windows systems is crucial to the success of Windows 2000, given that it is the newly re-architected, strategic replacement for Windows NT Servers and eventually also for Windows 95/98. From the perspective of IBM system users, Babylon in essence is a new version of the well-known Microsoft SNA Server gateway product which, as a component of Microsoft’s BackOffice suite, provides NT-centric host connectivity, SNA application access, and host data interchange. However, given that Babylon also addresses UNIX and NetWare related interoperability, its scope extends beyond SNA Server and also embraces other Microsoft offerings, such as: • Services for UNIX • Services for NetWare • Microsoft Data Access Components (MDACs) A formal definition of Babylon, à la Microsoft, would be that it is an Enterprise Integration Server platform for application and data interoperability between Windows 2000 and IBM OS/390 (including MVS), IBM OS/400 for AS/400s, UNIX, and NetWare. In addition, a complementary initiative

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

239

HOST INTEGRATION AND APPLICATION SERVERS code-named “Latinum” deals with business process integration, document interchange, and workflow management across applications on both an intra- and inter-company basis. The underlying goal of Babylon and Latinum is to make Windows 2000 servers the indispensable focal point of enterprise computing. With Babylon, Microsoft is trying to reduce the role of mainframes and AS/400s to be mere data servers and repositories of legacy transactions. According to Microsoft’s vision, all new transaction processing and data access, particularly for the new genre of Web-centric applications including those for E-commerce, will be done within a framework of Windows 2000 servers — with a three-tier architecture where Babylon and Latinum features will provide the necessary access to non-Windows systems. Thus, for example, data replication — either on on-demand or on a regularly scheduled basis between IBM DB2 databases and Microsoft’s SQL Server for Windows 2000 — is a key component of Babylon. What makes this emphasis on replication incongruous is the powerful Open Database Connectivity (ODBC) and IBM Distributed Relational Database Architecture (DRDA)-based capabilities already in SNA Server that permit transparent access of DB2 data, using SQL, without the need for the data to be replicated on a Microsoft server. This type of ODBC/DRDA “passthrough” access, however, does not make Windows servers the focal point of the data access operation. Replication on SQL Server, on the other hand, does put Windows 2000 on center-stage and even sets the scene for a possible migration away from DB2 in the future. COM-ORIENTED INTEROPERABILITY When it comes to interoperability with IBM hosts applications, Babylon focuses on programmatic access, as opposed to terminal emulation-based access such as tn3270(E), which to date has been the stock-in-trade of traditional SNA gateways, including SNA Server. This makes sense given that there is a surfeit of potent terminal emulation-based access solutions already in place, including the new wave of Java-based offerings such as the IBM Host On-Demand, Eicon’s Aviva for Java, and Hummingbird’s HostExplorer Web. Babylon, however, will provide some amount of object-oriented, terminal emulation-based access somewhat analogous to the host access JavaBeans now available with Host On-Demand Ver. 3.0 and Eicon’s Avia for Java 2.0. Most of Babylon’s programmatic access schemes are based firmly around Microsoft’s proprietary, although popular, Component Object Model (COM) architecture for object-oriented application development. COM, which has been around since the early days of Windows 95, is the integrated object model for Windows platforms. It is supported by all of the other key 240

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise Microsoft offerings, including ActiveX, Active Server Page (ASP) technology for Web page and server enhancement, the widely deployed Internet Information Server (IIS) Web server, Microsoft Transaction Server (MTS), and program development tools such as Visual Basic, Visual C++ and Visual J++. Other popular contemporary program development tools (including Inprise/Borland’s Delphi and Sybase’s PowerBuilder) also support COM. Moreover, COM objects exist for most Windows-related functions. The primary shortcomings of COM, as perceived by the “non-Microsoft” community, is that it is very Windows-centric and is not based on a public domain industry standard. Consequently, COM ironically faces the same stigma that eventually undermined SNA in the early 1990s. Although it is widely used and easily accessible, as was the case with SNA, COM like SNA is seen as a proprietary, customer lock-in tool being exploited by an industry super-heavyweight — in this case Microsoft rather than IBM. The industry standard for object-oriented program development is the Common Object Request Broker Architecture (CORBA) specification that was developed by the Object Management Group (OMG). The problem is that COM, or to be precise the client/server version of COM known as Distributed COM (DCOM), is at odds with CORBA, and CORBA-to-COM interoperability is only possible using a COM/CORBA bridge of some type. Thus, a key criticism that will be regularly leveled against Babylon will be that it is not standards compliant. INTEGRATING IBM CICS, IMS, AND DB2 TRANSACTIONS Babylon’s main technology for permitting clients to access CICS, IMS, or DB2 transaction applications running on mainframes is referred to as COM Transaction Integrator (COMTI). COMTI is a COM-based scheme that works in conjunction with Microsoft Transaction Server (MTS). COMTI, in essence, extends the scope of MTS to include CICS, IMS, and DB2 transactions. COMTI takes host transactions and creates a corresponding COM object that can be used to invoke and execute that host transaction. These COMTI objects representing host transactions can now be easily embedded within new applications, being written in languages like Visual Basic or Visual J++, using COM and DCOM methodology. Exhibit 20-1 depicts the general architecture of COMTI vis-à-vis mainframe CICS and IMS. What makes COMTI rather slick, and one could even claim somewhat compelling, is a Microsoft-provided tool (or so-called “wizard”) known as COMTI Component Builder. COMTI Component Builder, which is a Windows application, is able to automatically scan the source code of COBOL or PL/I programs that perform CICS, IMS, or DB2 transactions and identify the data definitions used to conduct the transaction. It will then dynamically create 241

HOST INTEGRATION AND APPLICATION SERVERS

Exhibit 20-1. The COMTI architecture vis-à-vis mainframe CICS and IMS.

a COM component “Type Library” (i.e., a .tlb file) that represents the transaction as a reusable COM component (or object). Once the corresponding .tlb files have been created, the mainframe transactions appear to Windows applications as any other MTS component. Consequently, components representing mainframe transactions can be readily, transparently, and profitably integrated with other MTS components to build complex distributed applications using a three-tier architecture — with a Windows 2000 server with MTS in the middle, as shown in Exhibit 20-1. MTS components can be easily integrated with Web page content on Internet Information Server (IIS) Web servers using Microsoft’s Active Server Page (ASP) technology. Thus, mainframe transactions represented by MTS components can be readily embedded within Web pages for access via Web browser-based applications. Given that the component-based integration is performed at the server, using ASP, these browser-based applications will not require Java or ActiveX applets at the client end in order to execute the MTS components. This notion of browser-based access to mainframe transactions using COMTI is also represented in Exhibit 20-1. COMTI does not require any Microsoft-supplied or Microsoft-specific software at the mainframe end. Instead, MTS interacts with the mainframe 242

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise applications via SNA Server as shown in Exhibit 20-1. These mainframe interactions are realized using an SNA LU 6.2-based programmatic approach, as opposed to a “screen-scraping” terminal-emulation mode. In the case of CICS, Microsoft will most likely use the client/server-oriented CICS External Call Interface (ECI), while the interface to DB2 will most likely be DRDA. Given that mainframe transaction subsystems now support TCP/IP-based communications, Babylon will support COMTI in TCP/IP mode as well as SNA. 2-PHASE COMMIT AND COMTI “2-phase commit,” a prerequisite for the successful, error-free execution of distributed transactions that involve two or more separate database updates, is also supported by COMTI. Those familiar with SNA LU 6.2 program-to-program communications will note that support for integrated 2-phase commit has been a much-publicized highlight of LU 6.2 since its inception in 1982. 2-phase commit ensures that the permanent updates to all the databases involved in a distributed transaction are only applied if and when the entire transaction is successfully executed. This avoids the danger that some databases may get updated, and others may not, if an error is encountered during the processing of the transaction. Take an example where a distributed transaction involves the transfer of funds from two bank accounts, one in London and the other in Paris, to a new account in New York — along with all of the necessary currency conversions and bank fee payments. One would not want the funds to be permanently withdrawn from the accounts in London and Paris until the deposit of those monies to the New York account is unequivocally assured. 2-phase commit provides a mechanism whereby the permanent updates to all three accounts can be applied together once all parties involved in the transaction have agreed that the transaction is no longer capable of failing. 2-phase commit uses the notion of database “check-pointing” and “rollback” to ensure that the integrity of a database can be restored, and any changes made to it cleanly undone, if the transaction fails. With 2-phase commit, there is a designated software agent, on one of the systems involved, that is responsible for overseeing the entire transaction. This agent makes sure that no updates are applied to a database prior to a checkpoint being created. Once the updates have been made, albeit at this juncture on what is still a temporary basis, the agent asks all the databases involved, with the exception of the last one in the chain, whether they can commit, unconditionally, to making those changes permanent as soon as the last database involved indicates that the transaction did indeed complete successfully. Once the agent has received positive commitment from all of the databases contacted, it asks the last database in the chain to go ahead and 243

HOST INTEGRATION AND APPLICATION SERVERS make its update permanent. When it receives confirmation that this permanent update was successful, it notifies the other databases to go ahead and make their changes permanent too — per their original commitment to making these updates. The term “2-phase commit” reflects this two-step “are you ready,” followed by “OK, now go ahead and make those changes permanent” approach of this scheme. If the agent receives a negative acknowledgment from any of the databases during this process, it will immediately terminate the transaction and order all the databases to roll-back the temporary updates they have made — and restore the contents of the database to correspond to the checkpoint that was made prior to the start of the aborted transaction. COMTI supports 2-phase commit between MTS and one or more mainframe transaction applications. Thus, it would be possible to now have the safety of 2-phase commit for a distributed transaction involving MTS, CICS, DB2, and IMS. (In the case of IMS, Ver. 6.0 with the IBM Resource Recovery Services [RRS] feature is required for 2-phase commit processing with COMTI components.) COMTI: SOMETHING OLD, SOMETHING NEW, AND SOMETHING BORROWED Although Microsoft explicitly positions COMTI as the primary application interoperability scheme between Windows 2000 environments and IBM mainframe applications, COMTI per se is not new. Instead, COMTI for CICS and IMS, albeit with 2-phase commit just for CICS, has been available with SNA Server 4.0 — which started shipping in late 1997. 2-phase commit for IMS was added with SNA Server 4.0 Service Pack 2 (i.e., SNA Server 4.2) that started shipping around February 1999. In reality, the only thing that Babylon adds to COMTI vis-à-vis CICS and IMS is the notion of hostinitiated transactions. This capability will enable CICS or IMS applications to invoke COM objects in the Windows environment — in the same way that COM objects are invoked from Windows applications. This will make COMTI bi-directional in terms of transaction invocation and provide programmers with total flexibility when it comes to structuring the execution order of a distributed transaction involving mainframe and MTS programs. Support for DB2, replete with 2-phase commit, will, however, be new with Babylon. So is the support for PL/I programs, given that the current COMTI Transaction Builder only works with source listing of COBOL programs. The other important COMTI enhancement that will be available with Babylon will be support for terminal-oriented applications such as IBM’s interactive TSO system. To realize this, COMTI will be extended to support both 3270 and LU-LU Session type 0-based transactions. At

244

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise Exhibit 20-2.

CICS and IMS DB2 Terminal Oriented TSO 3270 LU 0 Host initiated COBOL programs PL/I programs SNA to mainframe TCP/IP to mainframe Software developer kit

New COMTI technology as of Babylon.

With SNA 4.0 Since Late 1997

With SNA 4.2 Since Feb. 1999

Yes, with 2-phase commit for CICS

Yes, with 2-phase commit for IMS

New with Babylon in 2000

Yes, with 2-phase commit Yes Yes Yes Yes Yes Yes Yes Yes Yes

present, Microsoft is rather vague on how COM components will be created for these terminal-oriented transactions. It is possible that Microsoft will provide a tool that will read the 3270 or LU 0 datastream and automatically generate the appropriate objects in a similar manner to how objects are generated today based on the data definitions in COBOL programs. One aspect, however, that Microsoft is already stressing is that COMTI will enable the contents of multiple 3270 screens to be consolidated into one object. Thus, a transaction that necessitated interacting with multiple 3270 screens could now be realized using a single, graphical user interface (GUI)-based screen. This ability to combine multiple screens when rejuvenating a dated 3270 user interface has been available with contemporary rejuvenation solutions such as OpenConnect Systems’ OpenVista and 3270-to-HTML conversion products such as Novell’s HostPublisher. COMTI, a prominent pillar of Babylon, as discussed above, is thus in reality a continuum of functionality starting with the features available as of 1997 in SNA Server 4.0, as opposed to a single new capability. Exhibit 20-2 highlights what COMTI technology will be new as of Babylon and what functionality is already at hand prior to Babylon. MQSERIES-TO-MSMQ BRIDGE With exception of COMTI, Babylon’s only other application interoperability capabilities relative to mainframe and AS/400 applications are: • MSMQ-MQSeries Bridge • Direct access to AS/400 data queues

245

HOST INTEGRATION AND APPLICATION SERVERS Interestingly, and as with much of COMTI, the MSMQ-MQSeries Bridge is also not new. This capability, which enables messages to be seamlessly exchanged between the IBM strategic, cross-platform MQSeries middleware and Microsoft’s nascent Microsoft Message Queue Server (MSMQ), is available in SNA Server 4.2. Whereas COMTI sets out to tightly integrate MTS with the IBM market-dominating transaction processing systems, this message queuing-based bridge ensures that MSMQ can actively, but transparently, participate in MQSeries-based transactions — irrespective of the platform(s) on which MQSeries is being run. (IBM currently provides MQSeries servers on a wide range of systems, including OS/390, VM, VSE, AIX, AS/400, HP-UX, and Sun Solaris.) IBM is aggressively promoting MQSeries as a means of expediting the integration of applications on disparate platforms and as a means for Webenabling legacy applications. Hence, this ability to tightly couple with MQSeries is indeed extremely important to Microsoft’s goal of ensuring that Windows 2000 has appropriate hooks to all major enterprise information systems. Just as with DB2 data replication, this Bridge could be used down the road as a means of displacing one or more IBM MQSeries hosts in favor of Windows 2000 servers running MSMQ. This ability to displace proven and existing IBM technology with comparable Microsoft technology is obviously a resonating theme of Babylon. The MSMQ-MQSeries Bridge provides fully automated and comprehensive format conversion between the two systems to enable each system to send and receive messages in its own native format. This on-the-fly, bi-directional conversion is performed by the Windows 2000 server-resident bridge function. Microsoft claims that the bridge does not impose any restrictions to either MQSeries or MSMQ, and that all messages created by either system, irrespective of the APIs being used, are supported. At present, Microsoft is rather vague about the exact functionality of the AS/400 data queue access facility and how it will be made available. It is possible that this may be done using a message transfer scheme that may require the MSMQ-MQSeries Bridge. It is also not clear whether any Microsoft-specific software will be required on the AS/400 for this capability. Another option that may be possible would be to use a scheme based on DRDA. The mainframe and AS/400 applications-related interoperability envisaged by Babylon can now be summarized as follows: • COMTI for mainframe CICS, IMS, and DB2 • MSMQ-MQSeries Bridge • Direct access to AS/400 data queues At this juncture, it is interesting to note that Microsoft appears to be making an unnecessary and somewhat incongruous distinction between 246

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise

Exhibit 20-3.

DB2 to SQL server data replication using Microsoft’s Host Data Replicator.

mainframes and AS/400s when it comes to CICS and DB2. These days, CICS and DB2 are no longer mainframe-only solutions. Instead, IBM supports CICS and DB2 servers (or systems) on a wide range of IBM and non-IBM platforms, including OS/400, AIX, various UNIX systems, and even Windows NT — with standard interfaces, such as the CICS ECI, across all platforms. Thus, it seems strange that Microsoft does not attempt to extend its COMTI support of CICS and DB2 to include AS/400s and IBM AIX (e.g., IBM RS/6000] systems). DATA INTEROPERABILITY WITH IBM SYSTEMS SNA Server 4.0 provided record-level access to mainframe VSAM (i.e., flat files) and AS/400 Physical and Logical files via a feature known as Object Linking and Embedding Database (OLE DB) Provider. ODBC-based database access was also available. In addition, bi-directional data replication between DB2 databases and Microsoft’s SQL Server was possible using the “Host Data Replicator” adjunct to SNA Server. Exhibit 20-3 shows the architecture of Microsoft’s DB2 replication scheme. The IBM data interoperability capabilities of Babylon are built on top of these SNA Server 4.0/4.2 features and include: 247

HOST INTEGRATION AND APPLICATION SERVERS • OLE DB record-level access to mainframe VSAM, BSAM, QSAM, and Partitioned Data Set (PDS) files, and AS/400 Physical and Logical files with external record descriptions. With OLE DB, host data can be accessed from PC clients, without the need for data replication at a Microsoft server or at the client. OLE DB is supported by Microsoft’s visual development tools, including Visual Basic, Visual C++, Visual J++, and ActiveX scripting. In addition, OLE DB can be used with Microsoft’s ActiveX Data Objects (ADO) framework that facilitates easy integration with Visual Basic or browser-based access applications. • OLE DB provider for DB2, which uses DRDA across either SNA or TCP/IP to enable client applications (e.g., Visual Basic applications or browser-based access applications) to transparently access DB2 data. This scheme supports DB2 databases on a wide range of platforms, including OS/390, MVS, VSE, VM, OS/400, AIX, Sun Solaris, HP-UX, Windows NT, OS/2, and Compaq/DEC UNIX. As a part of this feature, SNA Server 4.2 includes a new optimized ODBC driver for DB2. • DRDA Application Server to facilitate DRDA-based relational database queries, involving multiple, heterogeneous distributed databases, from Windows applications. • Support for data warehousing using OLE DB and ODBC with DB2, Oracle and Sybase databases. UNIX AND NETWARE INTEROPERABILITY Version 2 of Services for UNIX available with Windows 2000 will provide the following new functionality: • Microsoft’s Active Directory (AD) interoperability with Domain Name Servers (DNSs) • Kerberos-based authentication for Telnet-based terminal access sessions • Secure interactions via a Microsoft-provided gateway with Network File System (NFS) v3 — with a file “auto-mount” capability • COMTI support for transactions based on the Transaction Internet Protocol (TIP) • UNIX account administration using Active Directory • Password file distribution using Active Directory Although interoperability with NetWare environments is an avowed goal of Babylon, in reality Microsoft adds little functionality to that already available today with NT Server 4.0 and Microsoft’s Services for NetWare. Today, Microsoft-provided gateway functionality ensures effortless file, print, and GroupWise (i.e., Novell’s e-mail, calendaring, and collaboration offering) interoperability — along with single sign-on between the two environments.

248

Microsoft’s “Babylon” — Windows 2000’s Interoperability for the Enterprise The only significant addition, as is to be expected, is a level of interoperability between Novell’s currently market-leading Novell Directory System (NDS) and Microsoft’s emerging Active Directory. This is achieved using Microsoft’s new MS Dirsync offering, which will initially support oneway directory synchronization from NDS to AD. With the war of the networks now over, with TCP/IP as the winner, the new battle lines are all about enterprise directories. Given its goal to control enterprise desktops and enterprise servers with Windows 2000, Microsoft, obviously, is very anxious to make sure that its AD initiative is not nipped in the bud by NDS. CONSPICUOUS OMISSIONS SNA Server 4.2, the prime IBM-related interoperability facilitator of Babylon, is inexplicably deficient when it comes to many basic SNA/APPN capabilities — including support for APPN network node routing. The most blatant omissions, at present, include: • lack of APPN and HPR NN based routing • end-to-end encryption, à la Secure Sockets Layer (SSL) security, for tn3270(E) and tn5250 sessions • “HPR-over-IP” (a.k.a. Enterprise Extender) functionality to enable full SNA data center-to-data center routing and Class-of-Service (COS) prioritization to occur across TCP/IP-based networks The IBM Communications Server family, which includes CS/NT Ver. 6.0, and Novell’s NetWare for SAA 4.0, SNA Server’s two primary competitors, offer APPN/HPR NN routing, SSL security for “tn” sessions, and support for HPR-over-IP. Microsoft’s rebuttal for the lack of this functionality is likely to revolve around the claim that host access that requires these features is now passé and that enterprises should instead focus on object-oriented access à la COMTI and OLE DB with ADO. SUMMARY OF BABYLON’S PRIMARY INTEROPERABILITY FUNCTIONS Application Interoperability: • • • •

Mainframe CICS and IMS: COMTI DB2: COMTI and DRDA Application Server Messaging: MSMQ-MQSeries Bridge AS/400: direct access AS/400 data queues

Data Interoperability: • Mainframe and AS/400 files: OLE DB • DB2: ODBC, OLE DB, OLE DB with ADO, DRDA, DRDA Application Server, and data replication with “Host Data Replicator” 249

HOST INTEGRATION AND APPLICATION SERVERS UNIX Interoperability: • • • • • •

Active Director <-> DNS Kerberos-based authentication for Telnet Secure interactions with Network File System v3 COMTI support for TIP UNIX account administration using AD Password file distribution using AD

Novell Interoperability: • One-way directory sync from NDS to Active Directory BOTTOM LINE ON BABYLON With Babylon, Microsoft sets out to provide proprietary, Microsoft-specific enterprisewide interoperability between Windows 2000 environments and IBM hosts, UNIX systems, and NetWare networks. The goal of Babylon is to ensure that enterprise computing, in the future, will become increasingly dependant on Windows 2000 servers — and any interactions with non-Windows systems will occur via a three-tier scheme where Windows 2000 is always in the middle. In the case of IBM hosts, most of the proposed technology is COM object based and is explicitly targeted at programmatic access via new client applications — including browser-based Web applications. The single-minded emphasis on COM, at the expense of the industry standard CORBA, may gall many and is likely to become a major objection leveled against Babylon by other vendors. An unstated, but nonetheless obvious underlying theme of Babylon is the notion that of presenting Windows 2000 servers as a viable alternative to certain IBM systems, in particular DB2-based databases and MQSeries-based application integration systems. Standards-based Java applications servers, such as the IBM WebSphere, Bluestone’s Sapphire/Web, Inprise’s Application Server, BEA WegLogic, and Novera’s jBusiness, are the obvious competitors to Babylon. As with the IBM SNA in the past, the fortunes of Babylon will depend heavily on whether enterprises are comfortable with proprietary technology from an industry behemoth — or instead want to keep their options open by sticking to industry standard solutions. SNA in the end has succumbed, albeit after three long decades, to TCP/IP — the now-universal standard for networking. The big question when it comes to Babylon is whether the Internet-inspired fervor for standards-based computing and networking will also extend to Windows 2000. If it does, then Babylon — like its namesake of old — will be in trouble. But on the other hand, there will be quite a few enterprises that will decide that they are so committed to Windows and Microsoft technology that anything major from Microsoft, as was the case in the past with IBM, is by nature a de facto industry standard. 250

Section V

Architectures and Programming Technologies SUN MICROSYSTEMS DEVELOPED THE JAVA LANGUAGE DURING THE EARLY days of the Web to provide a platform-independent language for Web-based computing. Since its inception and introduction, the Java language has been enhanced and extended with supporting technologies to support distributed and object-oriented computing. Chapters 21 and 22 of this section describe Java and JavaBeans. Since the mid-1980s, academia and industry have been working toward the goal of object-oriented programming. The promise of object-oriented approaches is that they will allow a magnitude of increase in the productivity of software programmers and an increase in the quality of software as a result. The Object Management Group (OMG) has been working for years to define standards for object design and communication. The Common Request Broker Architecture (CORBA) is its result. Microsoft has developed its own proprietary object model known as DCOM. Chapter 23 compares DCOM with CORBA.

251

Chapter 21

Java’s Role in Distributed Computing J.P. Morgenthal

ALTHOUGH JAVA IS RAPIDLY BECOMING THE PREMIER TOOL FOR BUILDING Internet applications, the fact that seemingly simple Internet applications, such as Web browsers, are actually distributed applications is often overlooked. Internet applications carry with them all the complexities associated with any distributed environment, although the severity of problems is admittedly lighter. The term “distributed applications” encompasses many technologies and development techniques, and a clear definition of it remains elusive. For clarity, a distributed application is one in which two or more components are cooperatively operating over a process boundary. The process boundary introduces the need for concurrency and shared memory. Concurrency represents the capability to share resources in a mutaully exclusive manner with all the guarantees that it implies. A growing trend in the industry today is transitioning existing enterprise applications to Web applications. Web applications are best defined as those that present a Hypertext Transfer Protocol (HTTP) interface for operation from within a Web browser. Employing this new motif for interacting with the user has given new life to many of these applications by creating a more intuitive user interface and expanding the platforms that can access it. Inside of the Web pages that represent this new interface are Java applets — code modules that can execute within a Java virtual machine — that enhance the Web browser’s ability to interact with the user. For many, this defines the extent of Java’s utility in developing distributed applications. This chapter presents a greater role for Java in the world of distributed computing. Java distributed computing represents a body of Java programming interfaces that enables Java applications to communicate with each other across a process boundary. The simplest form of this type of computing is two Java applications passing data over a Transmission Control Protocol/Internet Procotol (TCP/IP) network connection. The more complex form is two Java applications sending and receiving Java objects. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

253

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES JAVA’S BENEFITS Is Java hype or reality? Java is not a panacea for computing, but a very well-thought-out tool for building applications that need to operate in a networked environment. Like any tool, Java assists with certain jobs and is completely wrong for others. At this stage in Java’s technology adoption, users are trying to see what this new tool can do. Java has provided some immediate benefits through its use: 1. Owing to the nature of its programming language design, Java suits complex object-oriented development without some of the pitfalls associated with other languages in this category. For example, C++ requires detailed control of memory allocation and de-allocation. Java handles this automatically through garbage collection. This one small change in philosophy adds a tremendous amount of quality to software and reduces the number of problems caused with memory leaks and overruns. 2. The Java virtual machine is a widely accepted standard that is supported on all major commercial operating systems. Java’s design theoretically supports the concept of write-once/run-anywhere, but the mass deployment of virtual machines makes the theoretical concept a reality. 3. Java simplifies the deployment of applications in the organization. Some Java applications can be deployed as applets running on Hypertext Markup Language (HTML) pages in Web browsers. Still others can be full-blown stand-alone Java applications that automatically download their new components as a standard practice of the virtual machine. Here again, the promise of write-once/run-anywhere is an important one because these types of deployments are unencumbered by hardware and operating system differences. 4. Java offers the promise of consolidated development resources. Today, many IT departments are strangled by the different hardware and system software platforms requiring support. With Java on all these platforms, many of the specialized resources can be combined to work jointly on multi-platform efforts. These combinations also help to spread understanding of the business’ core applications across the development staff. 5. With companies clamoring to get at and manipulate their legacy data locked away on mainframe computers, a Java virtual machine can be a saving grace. IBM is currently porting the virtual machine for OS/390 and AS/400. Both of these machines store roughly 85 percent of corporate data today. Java will provide access to this data as well as offering new ways to process and distribute data throughout the organization. In general, it could be said that Java simplifies the development, deployment, and maintenance of applications in the enterprise. Because most 254

Java’s Role in Distributed Computing applications in this environment are for data entry or data retrieval, Java offers enough capabilities and performance today. For some specific applications such as computer-aided design or real-time monitoring, Java cannot provide the performance or features required. Java’s strong suit is thus development of distributed applications — applications that are partitioned into multiple tasks running on different machines. DISTRIBUTED JAVA APPLICATIONS Network application programming is never a trivial task, but sending and receiving a simple set of data over the network using Java is greatly simplified. However, there is far more utility when the communicating components maintain context along with the data. To accomplish this, not only data needs to be transmitted, but its functional and structural components as well. Existing distributed computing middleware currently supports maintaining context by using references to running executables. Generally, these references are literal strings that identify the machine where the executable is running. Distributed Java also maintains context as references, but the references are fully functional Java objects. To define Java distributed computing, one must understand the differences between applications running in the same address space and those running in different address spaces. Two Java applications running in the same address space can simply call functions on each other as long as the functions are programmed to be exposed publicly. In this case, there are no barriers stopping this behavior; however, when the applications are running in separate address spaces, there is a virtual barricade that surrounds each application. This barricade stops one application from seeing and being able to call functions into the other address space. The only way to subvert the virtual barricade is to make the function calls by passing the data over defined pathways into and out of it. In Java, the facility that performs this subversion is called Remote Method Invocation, or RMI. To provide some familiar vocabulary that will help provide context for Java applications, applications that expose their functions publicly are sometimes referred to as servers, and the applications that call them are referred to as clients. Hence, the client/server paradigm that has become so popular applies again with the rise of Web applications. When discussing these terms relative to a pure-Java application, applications that expose their functions publicly are referred to as remote Java objects and the applications using them are referred to as Java clients. Remote Method Invocation The Remote Method Invocation facility is core to distributed Java and defines a framework for Java-to-Java application communications that extends Java over process boundaries in a natural manner. Designed using 255

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES techniques learned from the experiences of the Distributed Computing Environment’s (DCE) Remote Procedure Calls (RPC) and Common Object Request Broker Architecture (CORBA), Java RMI is an advanced interobject communications system. The primary difference between interapplication and inter-object communications is the requirement for interobject communications to support pass-by-value for objects. Pass-byvalue is explained in detail later. As previously stated, RMI extends Java naturally over process boundaries. This means that Java communicates with remote objects — those in another address space — in a manner that is transparent to the user. That is, remote Java objects will behave in the prescribed manner of all Java objects. By upholding this contract, remote Java objects will support the same behavior of a local Java object providing the desired local/remote transparency that is one of the core focuses of distributed computing. To accomplish this level of local/remote transparency, three important requirements must be met: 1. The two communicating components must agree on a common messaging protocol. 2. The two communicating components must use the same transport mechanism, for example, TCP/IP networking protocol. 3. Code and data must be marshaled — packaged in a byte-oriented stream — in a consistent manner. The work on behalf of JavaSoft to develop and implement these requirements represents an outstanding body of computing research and technology. Actually, points 1 and 2 are fairly simple if experienced in network programming. However, the third point requires the cooperation of multiple Java subsystems, including Introspection, Object Serialization, Garbage Collection, and Remote Method Invocation itself. Introspection Java’s Introspection facilities allow the virtual machine to identify all of a Java object’s methods and fields from the Java class description. With this knowledge, the virtual machine can “flatten” Java objects from their inmemory state to a sequential stream of bytes. Once in the latter format, the object can be stored on persistent media or transferred over a network. This facility is not exposed directly to the programmer, for this would pose an opportunity to subvert the built-in security mechanisms. Instead, this facility is exposed through the Reflection programming interface and object serialization. Reflection is a programmatic interface for allowing Java objects to identify public, and sometimes private, methods and fields on Java objects. However, the method calls to the Reflection interface are checked by the 256

Java’s Role in Distributed Computing virtual machine’s security manager, thus allowing the security manager to restrict access. Of note, Introspection and Reflection can only be used on local Java objects. While a useful tool for building a remote procedure call mechanism, it cannot be used to examine remote Java objects. Therefore, the contract between the client and the server must be designed before the application is programmed. Object Serialization Object serialization uses Java’s powers of introspection to store and retrieve objects from a persistent form without requiring additional programming. To accomplish this task, the serialization layer must be able to identify and read all fields on a Java object. Furthermore, the serialization layer must define a format for flattened objects that allows for identification of class type and simplified retrieval. The data format chosen for object serialization is publicly distributed from JavaSoft with the Java Development Kit (JDK). This format implements certain required functionality for this facility. For example, if two fields within an object reference the same object, only one copy of the object is serialized along with the two individual references. This provides a level of integrity by ensuring that any changes to the object are reflected via both fields. This format also includes the class name for each object that is serialized so that the corresponding code can be associated when retrieved. Additionally, each serialized object is stored with a unique identifier that represents that object within the stream. This allows the object to be updated within the stream without having to serialize the entire graph again. A common problem associated with persistent objects is reconciling names. The Naming class is used by Java objects that wish to use remote Java objects and exposes an interface for finding and retrieving a reference to a remote object. These classes allow Java applications to implement RMI in a modular manner. That is, it does not make applications that use them reliant on any particular implementation of RMI, thus allowing RMI to operate over a host of networking protocols and vendor-independent implementations. The following is a sample RMI transaction. Sample RMI Transaction The transaction presented in the steps that follow is based on Sun Microsystems’ implementation of RMI that ships with the JDK release 1.1. Again, the only parts of this transaction that are vendor independent are the parts that use the Registry and Naming classes. 257

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES Step 1. A Java client object wishing to obtain a reference to a remote Java object running on a particular machine uses the Naming class to perform a lookup on that object. Step 2. If the remote object is running and properly registered in an RMI Registry on that machine, the Registry will return a reference. A reference in RMI is a Java object called a stub, which implements all publicly exposed methods on the remote Java object and maps the calls over the network. Step 3. The Java client object makes a method call on the remote Java object that requires an integer parameter. The stub object uses the object serialization facility to serialize the integer object into a stream, along with the method call signature, and delivers it to a dedicated listening network service called the skeleton. Step 4. The skeleton parses the serialized data from the client and builds a properly formatted method call on the remote Java object, which is local to itself. Any return values are serialized and passed back to the Java client. Exhibit 21-1 clarifies how the transaction operates. On machine 1, a client application uses the Java Naming class to access the Registry located on machine 2. This is done over a lookup operation. Upon successfully locating the requested object in the Registry, a Stub object is dynamically downloaded onto the client. The Stub and the Skeleton work in tandem to marshal data and method calls from the client application to the server application. The line from the Server to the Registry represents a registration process that must occur before the object can be located.

To simplify the transaction description, only an integer was passed from client to server. However, RMI implements the functionality to pass entire objects in this manner. To do this requires pass-by-value functionality for objects. This is a Herculean feat, requiring a system that can encapsulate

Machine 1

Machine 2

Client

Server

Stubs

Skelton

Naming Class

Registry Class

Exhibit 21-1. RMI transaction flow. 258

Java’s Role in Distributed Computing code and data together; without both there is no assurance that an object’s data will have the proper coherence. That is, pass-by-value transmits entire objects between process boundaries, including the explicit object being passed and all of its implicit objects defined as fields. When designing distributed systems, coherence will be maintained for explicitly passed objects, but implicitly passed objects may require code definition inside the remote address space. To accomplish this feat, Java builds on the object serialization facility that stores inside the object’s stream the name of the Java classes. These names are then used to request the Java class files to be transferred if they do not exist locally. The capability to pass classes in this manner is not unusual for Java as this is exactly how Web browsers retrieve Java applets from Web servers. Indeed, the logic inside of RMI to accomplish this uses the class loader functionality associated with automatically downloading Java applets. Ongoing debates in the industry illustrate the lack of appreciation by programmers for this capability: a severe problem for the industry’s overall growth. This is most noticeable in technical discussions at industry events and over the Internet in which developers argue that Java-to-Java communications could have been handled by existing inter-object messaging protocols. However, these existing protocols do not inherently support pass-by-value for objects or distributed garbage collection — both requirements of distributed Java. AGENT TECHNOLOGY The new capability to pass entire objects, and the objects they contain, has bred a new type of application called the agent. Agent technology is a rapidly growing field within the Java community. The primary reason for this rise is the solution that agents provide to the problem of possible disconnected network states. Java RMI, as well as all remote procedure call mechanisms, are highly synchronous. That is, the client issues a method call and waits for a response. If the network connection is broken at any time during this waiting period, the client application will never receive its response. This could cause the applications to “hang” or to enter into exception handling logic. Agents allow clients to send processing code to the server when the connection is up that will execute on the server. If the network connection breaks after the agent is delivered, the entire process can still continue normally. This is because agents work in an asynchronous manner; when the client wants the response to the processing, it will make a separate request to the server to return the agent and all of its collected data. Until the client receives this response, the agent will continue to exist, allowing the client to retry multiple times until it receives it successfully. 259

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES Java enables agents such as the Web browser to download an applet and call a method on it to start it running. It requires a contract between client and server to send and receive agents, but this is required of all distributed applications. The combination of synchronous and asynchronous programming allows one to design and build robust distributed applications that operate seamlessly across heterogeneous networked environments. CONCLUSION Many different solutions exist for distributing a task over multiple address paces and over a network. This chapter presented a method for inter-object communications within a pure Java environment. For some, the simplicity provided by the distributed Java platform may be reason enough to use it over other distributed computing technologies, such as the Common Object Request Broker Architecture (CORBA), OSF Distributed Computing Environment (DEC), and Distributed Component Object Model (COM). However, even if companies choose not to use this platform, the perceptions of how to build distributed applications have been forever altered. As this chapter was being written, Oracle, Netscape, IBM, and SunSoft submitted a proposal to the Object Management Group (OMG), requesting that the introspection and pass-by-value be incorporated into CORBA. Interestingly, these are the same features that provide the distributed Java platform with its power.

260

Chapter 22

Component Architectures with JavaBeans Doug Nickerson

WITH EACH NEW DEVELOPMENT IN SOFTWARE ENGINEERING, DEVELOPERS hope to have the solution — the silver bullet that will kill (or at least tame) the werewolf of software productivity. And indeed, methodologies and advances such as high-level languages, information engineering, rapid application development, application reengineering, and object-oriented programming have made software developers more productive. Still, advances in software productivity do not match the gains in hardware. Component software, the idea of creating applications from plug-in parts, is a recent weapon in the continuing battle against recalcitrant software projects. There are component architectures now available from a number of different vendors, with minor and major differences among them. Architectures such as JavaBeans, OLE, and ActiveX support technologies addressed to client-side applications. Enterprise JavaBeans, DCOM, and CORBA provide services for the server side. All of these promise to make development of applications easier, faster, and cheaper by using reusable and interchangeable component parts. This chapter focuses on component architectures — the backbone of what makes component software work. Just as a well-planned software project starts with an analysis of the problem to be solved, this chapter analyzes the need for components before describing them in detail. Discussion includes: 1. what component architectures try to accomplish — why they are needed 2. the minimum requirements a component architecture needs to be viable 3. the features of the JavaBeans from Sun Microsystems, a component architecture built on Java, as an example of one implementation of a component-based system 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

261

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES THE NEED FOR COMPONENTS Object-oriented programming, which dates back as far as the language Simula in the 1960s, is currently a widely popular development technique. Proponents of object-oriented programming cite its ability to create large applications from self-contained parts, applications that are easily maintainable, extensible, and benefit from extensive code reuse. Traditional object-oriented methods go far toward meeting the goals above. However, many experts would agree that objects have not become as easy to use as integrated circuits are for the hardware designer. The tight binding between an operating system and the binary code that runs in it hinders the reusability of objects. Objects are not always interchangeable between different operating systems or compilers. Object interchangeability is mostly achievable only when a project stays within one programming language and one computer type. For example, when writing a C++ program using an object class library, one might want to use objects provided by a vendor other than the library provider. There are two ways to go: the objects were written in C++ and have been compiled for use with a specific compiler and linker, or one has the source code for a C++ class that one can recompile and link them with one’s program. But one cannot select an object off the shelf, plug it in, and be sure that it will work. Component architectures are proposed as a solution to these problems. They make it possible to create interchangeable, self-contained units of functionality (components) that can work across different hardware and operating systems. To do this, they go beyond the basics of the object-oriented model and add other features. First, a brief review about the objectoriented model for analysis and programming. OBJECT-ORIENTED SOFTWARE Although the term “object” means different things to different people, the characteristics of encapsulation, polymorphism, and reusability (often through inheritance) are widely accepted features in the definition of object oriented. Encapsulation requires that both data and implementation (methods) of an object be encapsulated. Usually, data fields are made private and the object provides an interface to them. (Languages like C++ and Java do not prevent one from making public all the data in an object; one follows this approach as a stricture of good design.) Data and function encapsulation reduces the coupling of objects in a program: objects cannot change the data of another object without going through an interface or, when no interface is provided to internal data, 262

Component Architectures with JavaBeans perhaps have no data access. Encapsulation also eases maintenance by localizing changes to data fields or implementation of an object to one section of a program. Polymorphism is the ability to send the same message to different objects, and have the object behave differently — call a different method. The concept of reuse is often mentioned in the definition of objects. Although it is not the only method of reuse, object-oriented languages such as C++ and Java provide code reuse through inheritance. One inherits data fields and implementation of a base class (or superclass), creating subclasses that are specializations of the base class. COMPONENT ARCHITECTURES Component architectures have much in common with objects, especially the practice of data and functionality encapsulation. Unlike objects, they are required to be usable in many different computing environments, possibly bridging different operating systems or over networks. A component architecture solves the tight binding problem by providing a layer between the component and the operating system in which it is running. To a developer of components for a specific architecture, this layer is similar to a protocol like HTTP. If one creates a component in accordance with a specific component architecture (whether JavaBeans, OLE/COM, CORBA, or others), it works in any target environment that implements the particular protocol. Considering these concepts, one can generate a list of requirements for a component architecture, including: • a way to contain state information (data) • a way to provide functionality (callable functions) • a way to enable communication among components whose types and behaviors are not yet known • an ability to function across different computing systems/operating systems • customization features • persistence: a way for the component to be saved The data and functionality requirements are required for component encapsulation. The communication or connections between components are very important because components are to interact with other components in arbitrary software environments. Cross-environment functioning is the one of the hallmarks of components. For example, Microsoft’s Component Object Model (COM) defines a binary standard for the implementation of its COM objects. COM objects 263

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES can be coded in different languages as long as they are compiled to this standard. JavaBeans relies on the Java Virtual Machine to be present in the environment in which beans are running. because beans are Java classes, they will run wherever Java will run. Of course, this solution is a Java-specific one (JavaBeans are created in Java, whereas COM/ActiveX objects can be created in C/C++, Visual Basic, and other languages). Most architectures also provide the ability to customize components because it may be necessary during development. In a typical scenario, a component is loaded into a graphical application builder tool, and the developer uses it with other components to create a complete application. The developer can make changes to components, their appearance, location, etc. After the developer is satisfied with the application, it may be possible to save the components, retaining the changes made (this is called persistence). JAVABEANS: JAVA’S COMPONENT ARCHITECTURE JavaBeans, a component architecture that was introduced by Sun Microsystems in Java 1.1, is implemented in Java. How does JavaBeans meet the requirements in the previous section? From the language viewpoint, a component (a bean or JavaBean) is simply a Java class. Create a Java class, provide it with some simple facilities, and one has now created a component in Java. JavaBeans encourages one to follow some additional conventions (mostly naming schemes for methods), but a bean is still just a Java class. The first three requirements in the previous section can be summarized as data, functionality, and component connections. JavaBeans provides the features of properties, methods, and events to implement these features. The JavaBeans support for properties, methods, and events is based on built-in Java features. Once a developer knows Java, it is not necessary to discard knowledge of the language when learning JavaBeans. The trio of properties, methods, and events is discussed in more detail below. Properties Define a bean in JavaBeans by creating a Java class. Any properties required by the bean become normal variable definitions. The convention encourages one to make these variables private to the Java class and to provide an interface to them. The names of the methods accessing the data field use a standard naming convention to assist the reflection mechanism 264

Component Architectures with JavaBeans in discovering a property at runtime. The convention of providing interface methods encourages a design that uses data hiding. An example bean follows: public class SimpleBean extends java.awt.Canvas { private int intData; int getClassData() { return intData; } void setClassData (int inputVal) { intData = inputVal; } } // end class

In the above class, access methods have been provided for the local data of the bean SimpleBean. Were this bean running in a container application supporting JavaBeans, JavaBeans would analyze the names of these methods and discover a property named ClassData. In Java terminology, the method by which the properties, methods, and events of a bean are analyzed is called introspection. The integer data field intData can have a different internal name than the external name, classData. Methods Once one has decided what functionality is required as an interface to a bean, one can define public methods in the usual way. A bean can contain other methods besides its public interface; methods not called by client code outside the bean can always be declared private. As mentioned before, there are naming schemes (in JavaBeans terminology, called design patterns) that one can follow — although not strictly required — to aid the introspection mechanism in finding methods at runtime in a container application. The getClassData/setClassData pair shown in the last example is an example of such a design pattern. The introspection of methods by a container application uses the reflection support in the java.lang.reflect and java.lang packages, which contain classes to represent constructors, methods, fields, and classes. This analysis code is the responsibility of the implementers of a bean container; the average bean user or developer does not have to worry about it. 265

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES Events: Component Communication Events are the methodology for linking beans in a container application. The Java 1.1 event model implements events by way of event sources and event listeners. A particular bean is designated as the source of an event; other beans listen for the event. The listener for an event usually responds by calling other methods on receiving the event. To listen for an event, a bean goes through a process called registration. The source of an event provides the means for registration. Effectively, the source bean keeps a list of other components that have registered. When it sends an event, it iterates through its list, sending an event to each listener in turn. The source also maintains list management code — code to add and remove beans from its list. This approach has certain efficiencies over the way events were handled in the first versions of Java (1.0, 1.02). It is more efficient just to deliver events to those objects that are interested in the events. The previous event model broadcast an event across the entire system. The programmer wrote a switch or case construction to distinguish one event from another and called a method for whatever response was required. JavaBeans provides support for customization and persistence through special classes. A user of a bean builder tool can customize the properties of bean in a design-time environment and save it. The bean can later be reloaded, and still has the same state it was saved with. Java provides additional JavaBeans support by way of its libraries. In particular, a special package java.beans contains support code for beans. These facilities are mostly used by a container environment. SOFTWARE CONTAINERS The ultimate goal of creating a component architecture is to be able to create plug-in components to use in a software project. An environment supporting a particular component architecture is broadly known as a component container. The container’s main responsibility is to provide the services necessary to support the component architecture. A container can be a complete application in its own right. Microsoft Excel and Microsoft Word can be programmed using Visual Basic by way of their support for an OLE technology called Automation. In this mode, they act as container applications supporting the OLE architecture. The first JavaBeans release included a bean container called the BeanBox. A container for JavaBeans uses the JavaBeans support to provide an environment to run and build with beans. A builder container would make 266

Component Architectures with JavaBeans heavy use of Java’s built-in reflection mechanism (reflection is similar to runtime type information in C++) to discover and analyze beans. A typical application builder would be able to scan the current environment for available beans, and present their properties, methods, and events to the developer. The user can use an application builder to develop an application with the beans, possibly modifying properties of various beans and connecting them to create a complete application. The persistence feature implies that the user can save the beans and reload them later without losing their context. OTHER INDUSTRY MODELS Although it is beyond the scope of this chapter to discuss other component architectures in detail, for comparison purposes some information on OLE is provided herein. Microsoft’s OLE was originally developed to link and embed objects among different Microsoft applications; for example, linking a spreadsheet with a word processing document. Today, the scope of OLE is much wider. The Common Object Model (COM), Microsoft’s component architecture, is the basis of OLE and ActiveX. OLE Automation and ActiveX controls, as well as many other OLE technologies, are based on COM. A developer uses COM by accessing the COM library to start up a COM server. A COM server can then load one or more COM objects. A COM object groups functions together by way of its interfaces. A COM object may have multiple interfaces, but always has at least one. Interfaces group related functionality together. A single interface would implement a certain service that the object provides. Functions of a certain interface might manage a telephone list: looking up a number, adding a number, etc. Another interface in the same object might support a different feature, an address database, for example. A comparison between JavaBeans and the COM is educational in studying the different approaches to meeting the requirements mentioned earlier. COM interfaces implement a type of function and data encapsulation; the user of a COM object must fetch an interface pointer before accessing any object services. Data from a COM object is usually not accessed directly. COM objects also have a type of two-way communication using connectable objects and events (also called notifications). In terms of ease of use, Sun Microsystems has made much of the fact that JavaBeans is implemented on top of Java in a natural way, introducing very few new concepts or support libraries to the developer interested in creating beans. And, in fact, Microsoft’s OLE/ActiveX does require a larger 267

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES Exhibit 22-1. Checklist for evaluating or learning a new component technology. 1. 2. 3. 4. 5. 6. 7. 8.

How is data and functionality addressed in the technology (properties and methods)? How do components interact in the technology (the event model)? What is important to you and your organization? Assess the technology in those terms. Is cross-platform development important? Is it important to develop components in multiple languages? Is extensibility important? How is customization and persistence of components accomplished? Are they easy to use? Does the component technology require learning a whole new way of thinking? Or, like JavaBeans, does creating components merely involve using some features of the existing environment in a different way?

investment in learning new concepts, familiarity with COM and with the COM library. If evaluating or learning a new component technology, ask the questions listed in Exhibit 22-1. References 1. Brockschmidt, Kraig, Inside OLE, 2nd ed., Microsoft Press, 1995. 2. Chappell, David, Understanding ActiveX and OLE, Microsoft Press, 1996. 3. Cox, Brad, Object Oriented Programming: An Evolutionary Approach, Addison-Wesley Publishing, 1987. 4. Flanagan, David, Java in a Nutshell, 2nd ed., O’Reilly, 1997. 5. Nickerson, Doug, Official Netscape JavaBeans Developer’s Guide, Ventana, 1997. 6. Yourdon, Edward, Decline and Fall of the American Programmer, Prentice-Hall, 1993.

268

Chapter 23

Evaluating Object Middleware: DCOM and CORBA T.M. Rajkumar and Richard J. Lewis

OBJECTS

IN THE FORM OF SOFTWARE COMPONENTS ARE CHANGING THE

way applications are developed and delivered. Component technology breaks the application into intrinsic components and then glues them to create the application. Using components, the application is easier to build, robust, and delivered quicker. Middleware is used as the object communication bus to enable distribution of these components across heterogeneous networks and operating systems. The need for reliable distributed computing middleware environments is becoming pressing as three-tier client/server networks become commonplace. Although much of the industry backs the Common Object Request Broker Architecture (CORBA) as the standard object bus, Microsoft is pushing its own Distributed Component Object Model (DCOM). Managers and system architects have to determine what object bus to use in their companies. This chapter reviews the two primary forces in distributed object technology: CORBA and DCOM. It discusses their individual strengths and weaknesses across a wide spectrum of categories, and gives some sensible advice on what technologies might be best applicable to a system development manager’s current projects. Finally, it takes a look into what the future has in store for these architectures. WHAT IS CORBA? CORBA is a set of distributed system standards promoted by an industry standards group called the Object Management Group (OMG). The idea behind CORBA is to allow applications to communicate with one another no matter where they are located or who has designed them. The CORBA standard defines the ORB, a mechanism through which distributed software and their clients may interact. It specifies an extensive set of busrelated services for creating and deleting objects, accessing them by name, 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

269

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES storing them in persistent store, externalizing their states, and defining adhoc relationships between them. History The OMG has more than 700 member companies that have been working on the CORBA standard for eight years. CORBA 1.1 was introduced in 1991 by the OMG and defined the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB). CORBA 2.0, adopted in December 1994, defines true interoperability by specifying how ORBs from different vendors can interoperate. Since 1989, the OMG has been working to create standards for objectbased component software within the framework of its Object Management Architecture. The key component is the Common Object Request Broker Architecture (CORBA); this specification was adopted in 1991. In 1994, CORBA 2.0 defined interoperability between objects in heterogeneous systems. Since then, the world has seen a growing list of CORBA implementations come to market. Dozens of vendors have recently announced support for the CORBA Internet Inter-ORB Protocol (IIOP), which guarantees CORBA interoperability over the Internet. Specifications of several generally useful support services now populate the Object Services segment of the architecture, and work is proceeding rapidly in specifying domain-specific technologies in many areas, including finance, health care, and telecommunications. CORBA Architecture The five main elements of the object management architecture, shown in Exhibit 23-1, are: • ORB: defines the object bus and is the middleware that establishes the client/server relationships between objects. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. • Object services: define the system-level object frameworks that extend the bus. These include services such as security, transaction management, and data exchange. • Common facilities: define horizontal and vertical application frameworks that are used directly by business objects. These deal more with the client than the server. • Domain interfaces: interfaces like common facilities but are specific to a certain domain, such as manufacturing, medical, telecommunications, etc. 270

Exhibit 23-1. The main elements of the object management architecture.

Evaluating Object Middleware: DCOM and CORBA

271

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES • Application interfaces: objects defined by the developer to solve the business problem. These interfaces are not standardized. ORB Component and CORBA Structure Interface definition language (IDL) stubs provide static interfaces to object services. These define how clients invoke corresponding services on the servers. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, the communication protocol that is used, or any other system aspects that are not part of an object’s interface. The CORBA structure shown in Exhibit 23-2 specifies the workings of the ORB component of the OMG specification. While IDL stubs are static, dynamic invocations enable the client to find (discover) at run time a service that it wants to invoke, obtain a definition, issue a call, and return a result. On the server side, the object implementation does not differentiate between static and dynamic invocations. The ORB locates an object adapter, transmits the parameter, and transfers control to the object implementation via an IDL skeleton or a dynamic skeleton interface (DSI). The IDL skeleton provides support for the IDL-defined methods of a particular object class. The DSI provides a runtime binding mechanism for servers by inspecting the parameters passed by the message to determine the target object and method. The object adapter accepts the requests for service on behalf of the server objects. If necessary, it starts up server processes, instantiates or activates the server objects, assigns an object ID (object reference), and passes the requests to them. The object adapter also registers the classes it supports and their runtime object instances with the implementation repository. Object adapters are specific to each programming language, and there can be multiple object adapters for every object. Inter-ORB protocols allow CORBA products to interoperate. CORBA 2.0 specifies direct ORB-to-ORB interoperability mechanisms when the ORBs are resident in the same domain (i.e., they understand the object references, IDL type system, etc.). Bridge-based interoperability is used otherwise. The bridge then maps the ORB-specific information across domains. General Inter-ORB protocol specifies the transfer syntax and a set of standard message formats for ORB interoperation. Internet Inter-ORB Protocol is the implementation of this specification over a TCP/IP network. These systems also support inter-object references to locate and identify an object over the TCP/IP network. 272

Exhibit 23-2. CORBA structure specifying operation of the ORB component.

Evaluating Object Middleware: DCOM and CORBA

273

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES CORBA IN THE REAL WORLD CORBA has been around for a long time, but differences in early CORBA implementations made application portability and interoperability between implementations difficult. Different CORBA implementations fragmented an already small market, thereby rendering CORBA ineffective. Only recently have issues such as interoperability been addressed. Other recent events have given rise to the hope that the industry can overcome these early missteps. First, the World Wide Web has created an incentive for a mainstream component architecture. Second, Netscape, Novell, and Oracle have licensed the Visigenic Software ORB, targeting one CORBA implementation. And Netscape has the potential to propagate large numbers of that implementation in its browser, which could create critical mass. Third, IBM, Netscape, Oracle, and Sun have agreed to ensure interoperability between their CORBA and IIOP implementations. Still, these vendors are fighting an uphill battle, and significant interoperability problems remain. WHAT IS DCOM? Microsoft’s Distributed Component Object Model (DCOM) is object-oriented middleware technology that allows clients and servers in a distributed system to communicate with one another. It extends Microsoft’s component object model (COM) technology to work on the network. As is the case with Windows, Microsoft owns DCOM and controls its development. There will be no differing DCOM implementations to fragment the market, and Microsoft has begun shipping DCOM on both Windows NT and Windows 95. In other words, critical mass is quickly building. COM Architecture COM is an object-based framework for developing and deploying software components. COM lets developers capture abstractions as component interfaces and then provide binary classes that implement those interfaces. Encapsulation is enforced by COM such that client applications can only invoke functions that are defined on an object’s interface. COM interfaces define a contract between a COM object and client. They define the behavior or capabilities of the software component as a set of methods and properties. COM interfaces are implemented by COM classes. COM classes are bodies of code that implement at least one COM interface. All COM classes implement two functionalities: lifetime management and interface management. COM classes may implement several interfaces. COM clients must explicitly request the interface they need. It also lets clients widen their interface requirement at runtime, or query whether a component supports an interface. Lifetime management is accomplished by reference counting. 274

Evaluating Object Middleware: DCOM and CORBA COM classes reside in a server either as DLLs or EXEs. COM classes implemented as DLLs share the same address space (in process) as their clients. COM classes implemented within EXEs live in different processes (out of process) than their client. Such out-of-process clients are supported via remote procedure calls. COM classes are like meta classes. They create instances of COM classes, and also store static data for a class interface. For example, if a COM server has four different COM classes inside, that COM server will also have four class objects — one for each kind of COM class within the server. OLE is a set of system services built on top of COM for constructing compound documents that are also used for supporting components. OLE automation allows a component object to expose its methods through the Idispatch interface, allowing late binding of method calls. OLE controls (OCXs) provide exposure to the interface of an object using method pointer tables called vtables. COM’s binary interoperability standard facilitates independent development of software components and supports deployment of those components in binary form. The result is that software vendors can develop and package reusable building blocks without shipping source code. Corporate application developers can use COM to create new solutions that combine in-house business objects, off-the-shelf objects, and their own custom components. DCOM Architecture DCOM, or Distributed Component Object Model, extends COM to the network with remote method calls, security, scalability, and location transparency. With COM, objects can be loaded into the client’s process or launched in a separate process on the the same machine. DCOM extends this transparency to include location transparency, allowing objects to exist anywhere on the network. When the client and the object server are on different machines (see Exhibit 23-3), the remoting layer adds a proxy object in the client process space and a stub process on the server process space. The proxy object is then responsible for marshaling the parameters and makes the function call. The stub unmarshals the parameters and makes the actual function call on the component object. The results are then marshaled and sent back to the proxy object, where it is unmarshaled and given to the client. The entire process of creating the proxy and stub is invisible to both the client and the server, and they use remote procedure call as the interprocess communication mechanism. 275

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES

Exhibit 23-3.

A COM object and an invocation by a client.

ARCHITECTURE: CORBA VERSUS DCOM The member companies of the Object Management Group have shared one consistent vision of an architecture for distributed, component-based object computing since OMG’s inception in 1989. The architecture is described in the Object Management Architecture Guide, first published in 1990, and has been incrementally populated with the specifications of the core inter-object communication component (CORBA), and with common services for handling transactions, security, concurrency control, and other vital support functions for object-based applications. Both the architecture and the individual specifications are vendor neutral, and control of their technical direction and definition is via a public process that ensures broad cross-industry consensus. The specifications are available to all (OMG members or not), and free rights to implement software using the specifications are guaranteed by the terms of the OMG’s constitution. DCOM, a version of Microsoft’s COM, has deep roots in the client desktop GUI side as well as the server side. However, CORBA’s main focus has always been on the server side. ORB vendors in the past expected the nowdefunct OpenDoc to compete with Microsoft’s COM on the client side. Today, CORBA has no model specification to compete with desktop COM components for heterogeneous client GUIs. However, JavaBeans, a component technology from Sun, is being integrated to support client components 276

Evaluating Object Middleware: DCOM and CORBA with CORBA. This technology is still evolving. Until COM is ported to other platforms, however, Microsoft’s client-side advantage exists only on 32-bit Windows platforms. The CORBA Object Reference differs from DCOM’s Interface Reference in several ways. CORBA supports multiple inheritance of object interfaces, while DCOM has a mechanism that allows multiple independent interfaces per object. Interfaces. Both use the interface mechanism to expose object functional-

ities. Interfaces contain methods and attributes as common means of placing requests on an object. CORBA uses standard models of inheritance from object-oriented languages. DCOM/ActiveX uses the concept of multiple interfaces supported by a single object. DCOM requires that multiple inheritance be emulated through aggregation and containment of interfaces. Identity. Another difference is the notion of object identity. CORBA defines the identity of an object in an object reference that is unique and persistent. If the object is not in memory, the reference is used to reconstruct the object. DCOM, in contrast, defines the identity in the interface; the reference to the object itself is transient. This may lead to problems when reconnecting because the previously used object may not be directly accessible. Reference Counting. Reference counting is also different in both. A DCOM object maintains a reference count of all connected clients. It uses pinging of the clients to ensure that the clients are alive. CORBA does not need to do remote reference because its object reference model allows the re-creation of the object if it had been prematurely deleted. CORBA does not attempt to track the number of clients communicating with a particular object. If a client releases the object on the server while another is using it, the object will be destroyed and an error will return to the other client on the next method call. Thus, it is up to the object implementation to provide life-cycle management if such behavior is unacceptable. Without a transaction manager integrated into the distributed system, it is very difficult to implement a reliable life-cycle management system. APIs. CORBA uses two application protocol interfaces (APIs) and one

protocol for object requests. It provides the generated stubs for both static and dynamic invocation. In addition, a dynamic skeleton interface allows changes during runtime. DCOM provides two APIs and two protocols. The standard interface is based on a binary interface that uses method pointer tables called vtables. The second API OLE automation is used to support dynamic requests through scripting languages. 277

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES PROGRAMMING DCOM AND CORBA CORBA defines a finite set of primitive data types used for argument passing and structure definitions. CORBA interface definition language (IDL) files are similar in syntax to the C language, but deal only with interface-related details. Two of the primary differences between COM and CORBA are structure and naming. A COM object consists of one or more categories of interfaces, where each one is named and has its own derivation hierarchy. A CORBA object follows a standard object model; its interface is defined by its class and all the ancestors of that class. In the COM interface definition, the developer provides a universal identifier (UUID) that uniquely identifies the interface and class definitions. The UUID identifies classes instead of a class name so that one can have multiple classes with the same name but different vendors and functionality. CORBA, on the other hand, uses a naming system that includes the class name and an optional module name. Module names are equivalent to the C++ namespace concept, where class names can be scoped (assigned) to a particular module. The COM approach ensures that a collision will not occur. The CORBA version would allow a program to use two or more classes of the same name if their module scopes are different. Error conditions and the amount of information they return is another difference. CORBA implementations provide an exception mechanism that returns errors as a structure embedded within another object called the environment. A standard system exception structure is defined for systemlevel and communications errors that can occur during a remote method call. Because CORBA is generally implemented with an object-oriented language, the exception systems of CORBA and the language can be tied together. Thus, in C++, an error that occurs on the server will result in an exception being thrown on the client. In contrast, all methods in COM return an HRESULT integer value that indicates the success or failure of the call. This integer value is split into a number of bit fields that allow the programmer to specify context, facility, severity, and error codes, making error handling more laborious. The error-handling example is an area that CORBA is better at supporting than DCOM. Although both promote the aspect of location transparency, the reality that object implementations exist in other processes and the complications that can result from this are exposed in the way errors are handled. Developers like to know where an object exists when an error occurs. CORBA appears to be better, with its support for reporting system errors separate from application-level errors, which makes it easier for the developer to build appropriate exception-handling code. 278

Evaluating Object Middleware: DCOM and CORBA Existing Services. To quickly implement distributed object technologies, it is important to have a built-in core set of components that applications can use. While DCOM comes bundled with a few more than CORBA, both suffer from a lack of existing components.

SECURITY DCOM has a more flexible security implementation than CORBA. DCOM provides multiple levels of security that can be selected by the administrator. DCOM uses access control lists (ACLs) on COM components. Administrators can use ACLs to determine who has access to the objects. DCOM methods can also programmatically control authorization of individual method invocations. By combining NT APIs and registry keys, a method can implement custom security. DCOM’s security managers are platform dependent. However, they employ readily available authenticators from third parties. CORBA object services specify three levels of security. Level 0 specifies the authentication and session encryption using technology similar to that of the secure sockets layer (SSL) on Web servers. This requires that the IIOP be secure, and object servers have to register themselves with the ORB as secure. Levels 1 and 2 are differentiated based on whether the CORBA clients and server objects are aware of the security layer. In level 1, they are not aware; in Level 2, they are aware of the security layer. Because CORBA’s security specification has only recently been completed, ORB vendors have in the past had to come up with their own security implementations, which were incompatible with each other. Most vendors are currently only supporting SSL and Level 0 security. SCALABILITY Transaction processing (TP) monitors help with scalability of any application by providing two critical services: • process management: starting server processes, filtering work to them, monitoring their execution, and balancing their workloads • transaction management: ensures atomicity, consistency, isolation, and durability (ACID) properties for all processes and resources under its control Both DCOM and CORBA leverage TP monitors to provide for scalability and robustness. DCOM is designed to work with the Microsoft Transaction Server, which began shipping in early 1997. Transaction Server is a transaction processing system that enables development, deployment, and management of multitier applications composed of COM and DCOM objects. DCOM is used for all object communication among machines. Transaction Server transparently provides transaction support to objects: manages threads, processes, 279

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES ODBC database connections, and sharing data among concurrently executing objects. Although Transaction Server has a tight integration with SQL Server, it can be used with a wide range of databases. Transaction Server currently does not support failover and load balancing, although it is expected in future releases. In addition, DCOM is scheduled to work with a next-generation Directory Services, scheduled to ship with Windows NT 5.0. These services will provide a highly scalable store for object references and security information for DCOM. CORBA has a specification called Object Transaction Services (OTS) that is designed to interoperate with X/Open-compliant transaction monitors. Hence, CORBA OTS is designed to work both with ORB-based and traditional TP transaction processing services. OTS offers the capability of supporting recoverable nested transactions that support ACID and twophase commit protocols. IDL interfaces can be used to provide a way to access the TP monitor application remotely. Integrating TP monitors within an ORB allows the CORBA components to be wrappers of existing business functionality and to support legacy data. PLATFORM SUPPORT DCOM will currently only run on 32-bit Windows platforms. It is currently integrated into Windows NT 4.0, both server and workstation, and is available free for Windows 95. However, cross-platform support for DCOM is coming, with third-party ports coming for UNIX, including one for Linux, Digital UNIX, HP/UX, and Sun’s Solaris, as well as IBM’s MVS and DEC’s OpenVMS. Microsoft is actively seeking partners to port DCOM to other platforms, although some are concerned that Microsoft will favor its Windows-based implementations over the published DCOM standards. Applications using DCOM running on non-Windows platforms are only able to invoke the services on the Windows platforms, as opposed to allowing applications to be built anywhere. Among UNIX users, there is a driving need to have an easy means to connect application on the desktop and the server. Software AG, a developer of three DCOM-on-UNIX ports, estimates that of the 600,000 UNIX servers in production systems worldwide, about 80 percent need an easier way to bridge the worlds of UNIX and Windows. Critics of DCOM point out that the DCOM component model is not inherently distributed. It must be ported to every platform where it is to be used in order to get portability, which is clumsier than CORBA, which was built from the ground up to be distributed. In order for DCOM to be widely used for creating enterprise applications, cross-platform services such as Transaction Server and Message Queue Server must be in place. Although Microsoft is expected to provide 280

Evaluating Object Middleware: DCOM and CORBA versions of its COM-based messaging and transaction services on other platforms directly or through a third party, no formal commitment has been made. LANGUAGE SUPPORT CORBA is well-suited for use by object-oriented languages. The code is much cleaner because the bindings fully exploit the features of the host language. DCOM, on the other hand, has done nothing to provide management classes for the method arguments or a way to link error conditions to the C++ exception mechanism. CORBA also has a superior mechanism for handling arrays and sequences and provides an “any” data type for marshaling arguments whose type is not known in advance. For object-oriented languages such as C++, the DCOM interface is cumbersome and requires more low-level code. On the other hand, because DCOM supports OLE automation, applications can be developed with popular, non-object-oriented languages such as Visual Basic or Delphi. If developing a PC-based application within these environments, DCOM is definitely easier. For those dealing with object-oriented languages and significant object models, the CORBA model is more of a natural fit because of COM’s inability to support polymorphism and framework development. INDUSTRY SUPPORT Although many key companies such as Netscape, Oracle, and Sun Microsystems have agreed to support the emerging CORBA standards, there is some doubt whether they are fully committed to the standard, or if they will shift to DCOM if it gains considerable market share. DEC has announced it will use more than one technology, and HP has indicated interest in supporting COM on their versions of UNIX, but remains uncommitted to DCOM. Others, such as IBM, seem to be firmly backing CORBA. IBM has introduced a CORBA-based development suite of middleware products, including Component Broker Connector and Component Broker Toolkit, which it plans to offer free with many of its products. Tools vendors such as Oracle are hoping to find a middle ground in the battle for market share between DCOM and CORBA. Oracle has released a development environment that supports both native COM and CORBA components. MATURITY CORBA and DCOM have great potential for creating seamless distributed computing environments, despite the fact that today CORBA is struggling to 281

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES establish its standards and DCOM has yet to prove it can operate as a crossplatform solution. A Complete Tool? Although both architectures can create the structure for enterpriselevel applications, neither is capable of generating an actual enterpriseready application, which requires other services such as transactions, event notification, concurrency control, and naming. Although neither CORBA nor DCOM is a complete solution for network programming, CORBA offers good code for object-oriented languages. DCOM is easy to use with non-object-oriented languages such as Visual Basic. PERFORMANCE The network performance of DCOM is comparable to that of CORBA’s IIOP, with each accomplishing reasonable request/reply response times. However, a standard method of communicating over an asynchronous transport is needed for both DCOM and CORBA. Currently, because of their highly synchronous operation, these technologies are limited to operating over LANs and server backbones. Internet use, or use over a company WAN, is not practical with the current technologies because of the high rate of synchronous request/reply activity required. The OMG is in the midst of finalizing the Asynchronous Messaging service. This service extends CORBA’s synchronous processes and provides a notion of “store-and-forward” processing with a variety of quality-of-service guarantees for messaging, reporting, and similar functions. SUPPORT FOR THE WORLD WIDE WEB Netscape has declared the IIOP as its standard for communicating between distributed objects and has included object broker technology in Communicator and SuiteSpot. Microsoft continues to position Windows DCOM and ActiveX as its distributed object solution, and Explorer is the only browser to support ActiveX. Notification services are being provided in conjunction with the asynchronous messaging services in CORBA to enable an object to subscribe and receive notification of changes. This is essential to support the various push technologies emerging on the Web. Along with Event Services, this provides support for publish and subscribe to be effectively supported. Many CORBA vendors have provided support for this technology. However, they are not very scalable because, by their very nature, the Event Services uses a point-to-point connection-oriented approach. 282

Evaluating Object Middleware: DCOM and CORBA PROTOCOLS SUPPORTED DCOM supports several protocols, such as TCP/IP, IPX/SPX, and Named Pipes. Although not limited to IIOP, CORBA ORBs only support the TCP/IPbased IIOP or proprietary inter-ORB protocols. DCOM’s core network protocol is called Object Remote Procedure Call (ORPC). It is based on DCE RPCs (Distributed Computing Environment Remote Procedure Calls), with extensions such as the addition of a primitive data type to support object references. EASE OF USE DCOM has just a few key management tools, and has based the transport and security mechanisms on familiar Distributed Computing Environment (DCE) standards. This has made managing distributed components much less of a challenge. INTEROPERABILITY BETWEEN CORBA AND DCOM Currently, the IIOP is the OMG-approved method of linking distributed CORBA objects. Microsoft says it has no plans to support IIOP in DCOM, and there is currently no built-in COM support in CORBA. This battle of standards is making the implementation of both CORBA and COM services difficult. Because most enterprises will have both COM and CORBA environments, it is necessary that the objects in each be able to communicate with each other. OMG published a specification called “COM/CORBA Interworking” (now part of the CORBA 2.0 specification) that defines standardized mappings between COM and CORBA objects. There are several companies shipping implementations of this specification, including IONA, HP, Digital, and Expersoft. Basically, one of two approaches is used: encapsulation or converter. In the encapsulation approach, a call to the server object system is wrapped in an implementation of the object from the client system. ORB vendors provide generators to create such a bridge from the interface description of the object. In the converter approach, conversation proxies are generated during runtime based on the interface description of the object it represents. Both support bi-directional calls to and from either object system. THE FUTURE Microsoft is about to release a new version of COM called COM+. COM+ is designed to simplify the creation and use of software components. COM+ will provide a runtime and services that are readily used from any programming language or tool. It is intended to enable extensive interoperability between components regardless of how they were implemented. 283

ARCHITECTURES AND PROGRAMMING TECHNOLOGIES Where COM+ really shines, and where it most affects DCOM, is how COM+ addresses the difficulties inherent in writing component-based distributed applications. COM+ introduces an extensibility mechanism called interception, which receives and process events related to instance creation, calls, returns, errors, and instance deletion. Services that the Microsoft Transaction Server provides are a part of COM+, and thus will be a core part of future Microsoft operating systems. Similarly, the OMG is defining and filling in the services required for most of the service layers, such as directory service, transactions, and security. Vendor implementations of these are starting to appear. Others such as persistence, concurrency, time, query, trader, collection, and versioning will slowly trickle in over the next couple of years. In addition, Java Beans technology is being pushed as the client component technology, and Java support for CORBA is emerging. This may help provide additional support for CORBA on the desktop. CONCLUSION DCOM is more accessible than CORBA at this stage of the technologies because of Microsoft’s experience and focus on the included DCOM management tools. For Microsoft-centric companies, DCOM is a solution that is tightly integrated with the Windows operating system. Customers have the most to lose in the object wars, and interoperability between CORBA and DCOM will likely be an important issue for many years. Where cross-platform capability or access to legacy objects is required, CORBA is currently the clear winner. CORBA provides companies with the highest degree of middleware flexibility through its extensive third-party support. More likely, all enterprises will use a mix of the two technologies, with DCOM at the desktop and CORBA at the enterprise level. In essence, DCOM and CORBA provide similar enough services that debates of minor technical issues ought to be dismissed in favor of more practical concerns, such as scalability, openness, availability, and maturity. Other important issues to be considered are the operating systems and programming languages used in the current project. Availability of CORBA and DCOM bridges may render the choice moot, and users will not be aware nor care whether it is DCOM or CORBA under the covers because what they will use will be higher services (such as business facilities) built on top of either architecture. Recommended Reading Bowen, Ted S., Microsoft’s Cross-Platform DCOM Plans Raise Questions, InfoWorld, 19(20), 51, May 19, 1997. Dolgicer, Max, Deeper Inside CORBA, Application Development Trends, 41–46, Oct. 1997.

284

Evaluating Object Middleware: DCOM and CORBA Frey, Anthony, Is DCOM Truly the Object of Middleware’s Desire?, Network Computing, 8(13), 98, July 15, 1997. Gall, Nick, Three’s a Crowd with Object Lessons, Network Computing, 8(12), 101, July 1, 1997. Harzog, Bernd, Component Software War, InformationWeek, 632, 122, May 26, 1997. Kirtland, Mary, Object-Oriented Software Development Made Simple with COM+ Runtime Services, Microsoft Systems Journal, 12(11), 1997. Kotopoulis, Alexander and Miller, Julia, CORBA/DCOM Interoperability, Object Magazine, 68–77, July 1997. Kueffel, Warren, CORBA Masterminds Object Management, DBMS, 43–50, March 1997. Leach, Norvin, DCOM-to-Unix Ports on the Way, PC Week, 14(19), 8, May 12, 1997. Lewis, Jamie, Single Victor Unlikely in Object Protocol War, PC Week, 14(19), 93, May 12, 1997. McKay, Niall, HP to Push DCOM as Aart of CORBA, InfoWorld, 19(31), 6, Aug. 4, 1997. Pompeii, John, Programming with CORBA and DCOM, Byte, 22(4), 103, April 1997. Rajkumar, T.M., Client Server Development with Components, 1997. Roy, Mark and Ewald, Alan, Inside DCOM, DBMS, 10(4), 26, April 1997. Microsoft Corporation, COM and DCOM, http://www.microsoft.com/cominfo/, 1997. Montgomery, John, Distributing Components, Byte, 22(4), 93, April 1997. Object Management Group, CORBA vs. ActiveX, http://www.omg.org/activex.htm, 1997. Object Management Group, IIOP, http://www.omg.org/corba/corbiiop.htm, 1997. Object Management Group, What is CORBA?, http://www.omg.org/omg00/wicorba.htm, 1997.

285

Section VI

Security SECURITY IS A PARAMOUNT CONCERN FOR ANY IT MANAGER ENVISIONING opening up existing mission-critical applications and data to business partners over an extranet or even end customers over the Internet. End-to-end security for Web-to-host integration involves a number of different technologies at a number of different levels. This section covers the security aspects of Web-to-host integration in a great deal of detail. Chapters 24 through 27 provide tutorial-level information on the various types of security mechanisms that an enterprise should implement within a total framework for security. Chapters 28 through 30 deal with some specific elements of security that are important in Web-to-host environments.

287

Chapter 24

Framework for Internet Security Planning Monica J. Garfield and Patrick G. McKeown

AS

AN EASY - TO - USE INTERFACE THAT SUPPORTS SOUND , VIDEO , AND

graphical displays, the World Wide Web is being increasingly employed by organizations of all sizes for electronic marketing and advertising, customer service, and ordering centers. This growing commercial use introduces new opportunities as well as new security risks. Many security concerns stem from flexible design techniques used to build the Internet, some of which make it difficult to identify exactly where data and requests are coming from or where outgoing data will travel. Hackers are breaking into computers daily to sabotage or explore mission-critical data. Formulating a plan to thwart these curious onlookers and potential computer villains is no easy task because there are many ways unwanted intruders can attempt to gain access to a corporate computer and a range of measures available to help secure that environment. Given the loosely controlled Internet infrastructure, the best way an organization can protect its Web environment is to provide security at the front door. Before an organization can do so, Information Systems (IS) managers must first ask two questions: • What is the organization trying to secure? • What price is the organization willing to pay for this level of security? The answers to these questions provide the basis on which to formulate a security policy. This chapter presents a framework that helps IS managers assess the broad range of issues involved in the creation of an Internet security plan. It does not provide the technical details needed to deploy security measures but rather a road map of the options that should be considered. CONNECTING TO THE WORLD WIDE WEB The method an organization chooses to connect to the Web plays a major role in the level of functionality it obtains and the level of risk it faces. Exhibit 24-1 depicts the most common ways companies gain access 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

289

SECURITY Exhibit 24-1. Internet Access Options. Type of Connection Direct Indirect (through third party)

Enterprise Network Connectivity Yes No Full direct connection Full buffered connection

Stand-alone direct connection Standalone buffered connection

to the Web, each of which is associated with different degrees of flexibility, costs, and security risk. Full Direct Connection A full direct connection means that an organization has its own Web server directly connected to the Internet and to its enterprise network. This connection method has the greatest flexibility, the highest security risks, and potentially the highest start-up costs. It gives employees full access to the Web and the enterprise direct control over the Web site. The actual hardware and software costs to set up a simple Web server are not high — all that is needed is a machine that can run as a server, which can be a Windows-based PC, a Macintosh workstation, or a minicomputer, plus server software. This software is typically easy to use and understand. The higher costs associated with a full direct connection result from the organization’s need to protect the internal network from intruders. Securing a Web server from potential hackers requires a fairly high level of technical knowledge, because hackers are constantly improving their techniques. Full Buffered Connection A full buffered connection means that an organization has a Web server connected to the Internet through a third party and directly connected to the enterprise network. This type of connection is comparable to the full connection in terms of security risks but, depending on how the thirdparty vendor designs the Internet connection, may provide less flexibility. Although the third-party vendor can also set up most of the necessary security components, many companies believe that further security is necessary. Under this configuration, the organization must still purchase and maintain the server hardware and software. Stand-alone Connections Stand-alone direct connections and stand-alone buffered connections differ from full direct connections and full buffered connections because the Internet connection is not directly tied to the enterprise network. Would-be hackers therefore cannot gain access to the company’s network. 290

Framework for Internet Security Planning Exhibit 24-2. Degree of flexibility, costs, and security risk of internet connection options. Option

Flexibility

Degree Costs

Security Risk

Full direct connection Full buffered connection Stand-alone direct connections Stand-alone buffered connections

High Medium Medium Medium

High Medium High Medium

High High Low Low

Likewise, employees may not have a direct Internet connection. This option is the most secure but usually the least flexible. Many companies are implementing stand-alone buffered connections, in which Internet access not linked to the enterprise network is provided by a third party, through outsourcing. When a company outsources its Web needs, it subcontracts with another company that specializes in creating and maintaining commercial Web pages. The costs associated with this popular option vary significantly. Organizations must weigh the benefit of increased security against the disadvantages of not having direct access to the Internet. Exhibit 24-2 summarizes the degrees of flexibility, costs, and security risk associated with each of the four connection options. SECURING THE NETWORK ENVIRONMENT Securing a corporate network environment is similar to building a house. No amount of amenities can make up for the lack of a well-thought-out design plan and a solid foundation. Without these, the house will always be flawed. Security policies must also begin with a solid foundation in the form of virus protection and password integrity established before an Internet connection is obtained. Once the foundation has been laid, IS and security managers can build strong and secure protection for a corporate network by moving through five levels of security: • • • • •

patching and prevention of security holes encryption and authentication firewalls secure interfaces legal issues

The following sections review these levels and the options available within each. PATCHING AND PREVENTING SECURITY HOLES If virus protection and password integrity form the foundation of a secure environment, the patching of known security holes marks the beginning of a 291

SECURITY supporting frame. Many of these holes result from the fact that the Internet, and many of the protocols associated with it, were not designed to provide a high level of security. One known security hole results from the UNIX operating system, which was designed by computer engineers to make their work easier to manage. The UNIX OS lets an approved user log in from anywhere at any time to administer the system. By gaining access to the root, system administrators can manipulate all files that reside on the UNIX workstation and from there enter a corporate network. Unfortunately, unauthorized users who know how to exploit these features can do the same thing. Fortunately, much of the server software and many of the operating systems can be altered to greatly improve security. Although a knowledgeable system administrator can patch many of the holes in the security armor of a company’s server or network, others are not so easily fixed and still others are as yet unknown. As a result, one of the best ways to protect mission-critical information is to move it onto other servers or networks that are not connected to the Internet. Yet some critical information usually needs to be available on the portion of the corporate network accessible to the Internet. Several steps can be taken to improve the security of this information. Identifying Security Holes One way to begin to detect holes in the corporate server or network is to run a program designed to identify potential security risks. Many of these programs are controversial because they are also used by hackers. Yet it is precisely for this reason that organizations must use the programs, two of which are SATAN (Security Administrator Tool for Analyzing Networks) and Internet Scanner. Other steps a network administrator may take include turning off unneeded UNIX functions that provide security holes and changing the default passwords. Web servers can also be set up in unprivileged mode, and the root directory should not be accessible. Sending Network File System files outside the internal network should be prohibited, and sendmail and mail aliases should be restricted. If File Transfer Protocol (FTP) services are necessary, then the network administrator should restrict writable access to FTP’s home directory. Files in the anonymous FTP should also not be writable or ownable. Restricting remote log-ins (rlogins) and hiding domain name services also helps secure the corporate environment. Monitoring Hacker Activity Once known holes are patched, network administrators need to stay on top of who may be trying to break into their computers and as well as at 292

Framework for Internet Security Planning other Internet sites. Several mailing lists, such those run by the Computer Emergency Response Team provide updates of security violations. The alert mailing list, for example, can be subscribed to with an e-mail message to [email protected] that contains the message subscribe alert. Such information is also available from Web sites. Because only about 5 percent of all intrusions are detected and only 5 percent of these are reported, staying on top of who is trying to break into a corporate computer also requires that server logs be monitored for unusual activities. For example, one of the new ways for hackers to break into Web sites is to put rogue code onto a Web server by overrunning a software buffer. This gives an intruder unauthorized access to the account under which the HyperText Transfer Protocol (HTTP) process was running. When oversights such as this are found in the software, the Web server needs to be quickly patched. Copycat hackers are only too ready to exploit the system flaws found and advertised by other hackers. ENCRYPTION SOFTWARE AND AUTHENTICATION Once security holes are identified and patched, IS managers should consider encryption software and authentication. Encryption programs let users encrypt their communications so that they cannot be as easily read by unauthorized parties. Using such software can be likened to locking the doors to a house or sealing an envelope. Encryption programs apply cryptographic algorithms to break down ordinary communication messages (i.e., e-mail) into unique codes that can be unlocked only by individuals who possess the unencryption key. Encryption Public-Key Encryption. Public-key encryption is the most popular form of encryption, largely because of the program Pretty Good Privacy (PGP). PGP, which was created by Philip Zimmermann and uses Rivest-Shamir-Adleman algorithms to encrypt messages, is freely available on various Internet sites.

The basic premise of public-key encryption is that each user creates two unique keys, one that the user keeps and a public key that the user gives to others. The user then obtains the public keys of the desired recipients of a message and uses them to encrypt a file that only the receivers can unencrypt. Most users also sign their files with a unique signature (i.e., a block of characters) that receivers can verify by applying the sender’s public key to the message. Private-Key Encryption. Private-key encryption is less popular but considered to be robust. The main advantage of this form of encryption is that it lets users exchange their keys more securely than public-key techniques. The most popular private-key encryption software is MIT’s Kerberos. 293

SECURITY Hardware-Embedded Techniques. Some companies are moving toward encryption techniques embedded in hardware. PCMCIA (Personal Computer Memory Card International Association) cards can be manufactured with the capability to provide secrecy and authentication for the user. This technology is still in its early stages, so its usability and acceptance are uncertain.

Authentication Various techniques, some of which have no cost and others that are encryption-based, are available to verify the identity of a sender and the authenticity of a message. Authentication becomes increasingly important for ensuring that individuals ordering products over the Web are who they claim to be. Some authentication methods include: • Stipulating that a sender sign a message by citing something only the receiver and the sender would know (e.g., a discussion the sender and the recipient had the day before, a pet name, a favorite color). Obviously, this method works only when the sender and the receiver know one another. • Using a three-way handshake (i.e., sending a first message, having the receiver send a reply, and finally sending the actual communication). • Using a program that creates a unique digital signature for the user. Many encryption techniques have the capability to create such signatures. • Embedding a time stamp into an e-mail document. This method is primarily used to verify when a document was mailed (e.g., for legal suits and contract issues). FIREWALLS Firewalls are the dominant technology used to protect corporate networks from hackers. A firewall is a piece of software that lies between a company’s internal network and the Internet and forms a barrier to prevent hackers from gaining access. Drawing from the analogy of home design, the designer needs to decide where to put windows and reinforced doors in the walls of a house. If a company creates a firewall without any windows, people inside the company cannot see out into the Internet and use many of its services. Thus, firewall planning involves a trade-off between user flexibility and the level of security provided for the internal network. Although no firewall is perfect in this attempt, many come close. Once a corporation decides to put in a firewall, security personnel need to program the firewall to support the organization’s security needs. A firewall can be restrictive or flexible, depending on the company’s goals. For example, specific services such as File Transfer Protocol, which is one of 294

Framework for Internet Security Planning the most common ways for a hacker to break into a server, can be limited to reduce the probability of break-ins. The primary purpose of a firewall is to look at every piece of information that is sent either into or out of the internal network. Firewalls act on a message on the basis of user identification, point of origin, file, or other codes or actions. There are four basic actions a firewall can take when it looks at a piece of information: • The packet of information can be dropped entirely. • An alert can be issued to the network administrator. • A message can be returned to the sender after a failed attempt to send the packet through. • The action can just be logged. Several different types of firewalls protect the internal network at different network layers. The two most common types of firewalls are routerbased Internet Protocol (IP) level firewalls and host-based applicationlevel firewalls. Router-Based IP-Level Firewalls The router-based firewall focuses on packets — the basic unit of communications within the Transmission Control Protocol/Internet Protocol (TCP/IP), the most commonly used protocol for Internet communications. Router-based firewalls control traffic at the IP level going into or coming out of the internal network, blocking or passing along data packets depending on the packet’s header. They examine the network application service requested (e.g., FTP, Telnet protocol type) and the source and destination address of each packet that arrives at the firewall. The network administrator configures the packet-filtering firewalls to accept or reject packets according to a list of acceptable hosts, routes, or services. Unfortunately, when a firewall is reading these packets, network performance may slow down by as much as 20 percent. Other drawbacks of router-based firewalls include: • Firewalls do not allow for granular control of the packets. • They are cumbersome to code and when set up incorrectly may offer a false sense of security. • They usually do not log the actions that take place at the firewall, so the network administrator cannot monitor how hackers are attempting to break into the system. Host-Based Application-Level Firewalls Host-based application-level firewalls are considered more flexible and more secure than router-based IP-level firewalls. They reside on a host 295

SECURITY computer, typically a dedicated UNIX machine, PC, or Macintosh, and can be configured to support elaborate network access control policies with fine granularity. Application-level firewalls control network application connections (e.g., Telnet, FTP, SMTP) down to the individual or group level by type of action and time of action permissible. The ability to limit the time when certain functions run is particularly useful because many renegade hackers, dubbed “midnight hackers,” work late at night and network administrators need to be able to restrict many of the potentially unsecured Internet functions during those hours. One of the essential features of the application-level firewall is that it allows the network administrator to monitor a log of activities that take place at the firewall. This log can be used to identify potential breaches of security and to monitor resource usage. A recent rash of network break-ins has been accomplished by IP-spoofing. IP-spoofing takes advantage of the UNIX OS, which erroneously presumes that anyone who logs in to a server using a previously approved TCP/IP address must be an authorized user. By altering the source IP, someone can spoof the firewall into believing a packet is coming from a trusted source. To combat this problem, many firewalls reject all packets originating from the external network and carrying an internal source IP. SECURE INTERFACES The secure interfaces level of security is rather sophisticated, somewhat akin to installing a new form of support beams in a house. Secure interfaces are software programs that allow for additional security checks in the network interface. Several companies offer these interfaces, most of which work with the various Web browsers as well as with Web server software. The most common secure interfaces are Netscape Communications Corp.’s SSL (Secure Sockets Layer) and SHTP (Secure HyperText Transfer Protocol). SSL SSL sits between TCP/IP and HTTP or other protocols such as Simple Network Management Protocol or FTP. It provides privacy, authentication, and data integrity. MCI is one of the largest SSL users, employing the interface in InternetMCI. Other users include First Data Card Services (the world’s largest credit-card authorization firm), First Interstate, Old Kent, Bank of America, Norwest Card Services, as well as MasterCard International. S-HTTP S-HTTP extends HTTP to allow both the client and the server to negotiate various levels of security based on public-key encryption and provides 296

Framework for Internet Security Planning encryption, authentication, and digital signature features. It can also distinguish the origin of a particular document on any server. It was created by Terisa Systems, a joint venture between RSA Data Security and Enterprise Integration Technologies. S-HTTP’s strengths include its availability and flexibility. Both SSL and S-HTTP have been competing to become the standard secure interface for commercial sites on the Web. To head off the competition, Terisa Systems released a developers’ toolkit supporting both standards. Many other secure interfaces also exist, each with its own set of features. LEGAL ISSUES Many companies overlook the potential legal issues associated with connecting to the World Wide Web. The press has focused attention on many of these issues, including the availability of child pornography, bootlegged software, and ease of infringement of copyright laws. IS managers should be aware of these potential dangers and take measures to protect employees and enterprises from lawsuits and loss of valuable copyrighted data. This layer of security is comparable to household plumbing, which allows for unwanted items to be flushed away. For example, if FTP access to the server is allowed, network administrators should consider either prohibiting external users from placing files on the server or frequently purging files off the server. This guards against unwanted guests using the server as a clearinghouse for pirated software. One well-publicized case of such an incident occurred at Florida State University, where unknown individuals employed a seldomly used computer as a storage facility for pirated software. It is not implausible that the owners of the server may be found liable for what resided on the computer, regardless of whether they had knowledge about it, and be brought to court on copyright infringement charges. To curb access to sexually explicit materials, many companies are restricting access to a variety of UseNet groups. Although this practice may cut off the source of some illicit materials, users have other ways of gaining access to such materials. Companies cannot monitor the actions of all employees, but they may be able to reduce the likelihood of access to inappropriate sites by educating employees on what type of behavior will not be tolerated and aggressively enforcing such stances. Employees also need to be educated on copyright laws. Although it is fairly well-known that copying commercial, nonshareware computer programs is illegal, other forms of copyright infringement are less obvious. Downloading a copy of a favorite song or distributing an article found on the network without permission may violate copyright laws. 297

SECURITY Companies need to be concerned not only with what employees obtain but also with what they post outside the company. Employees may unwittingly release strategic information over the Internet, thereby jeopardizing data or potential profits. The only way to guard against such situations is through employee education that also encourages people to contact their IS manager, in-house counsel, or network administrator when they have questions. CONCLUSION The field of security and the threats to a corporate network will always be changing. The first step IS managers can take to secure a corporate network is to understand the range of security issues associated with Internet and Web access. The desired level of security must then be determined and security measures implemented. Security needs to be viewed as a holistic process because it is only as strong as its weakest link. Remaining aware of new developments in the field and continually adjusting security measures is one way of meeting the changing risks inherent on the Internet. Some of the more recent, yet still uncommon developments include HERF guns (high-energy radio frequency guns) and EMPT bombs (electromagnetic pulse transformer bombs). Both of these threats can wipe out an entire data center, and the only way to be protected from them is to put corporate servers and data sources underground and secured in heavy paneling. By monitoring server logs, staying alert to new security hazards, and altering the security system as needed, companies may be able to deter unwanted guests from visiting the corporate network. Organizations must also have adequate back-up plans that speed up recovery from the potentially devastating damages resulting from a successful security breach.

298

Chapter 25

Developing a Trusted Infrastructure for Electronic Commerce Services David Litwack

THE USE OF INTERNETWORKING APPLICATIONS FOR ELECTRONIC COMMERCE has been limited by issues of security and trust and by the lack of universality of products and services supporting robust and trustworthy electronic commerce services. Specific service attributes must be addressed to overcome the hesitation of users and business owners to exploit open systems — such as the Internet — for commercial exchanges. These service attributes include: • Confirmation of identity (nonrepudiation). This indicates proof that only intended participants (i.e., creators and recipients) are party to communications. • Confidentiality and content security. Documents can be neither read nor modified by an uninvited third party. • Time certainty. Proof of date and time of communication is provided through time stamps and return receipts. • Legal protection. Electronic documents should be legally binding and protected by tort law and fraud statutes. SERVICE ATTRIBUTE AUTHORITY To support these service attributes, an organization or entity would need to provide: • certificate authority services, including the registration and issuance of certificates for public keys as well as the distribution of certificate revocation and compromised key lists to participating individuals and organizations • a repository for public-key certificates that can provide such keys and certificates to authorized requesters on demand 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

299

SECURITY • electronic postmarking for date and time stamps, and for providing the digital signature of the issuer for added assurance • return receipts that provide service confirmation • storage and retrieval services, including a transaction archive log and an archive of bonded documents These service attributes could be offered singly or in various combinations. The service attribute provider would have to be recognized as a certificate and postmark authority. The following sections describe how a service attribute provider should work. Certificate Authority Although public-key encryption technology provides confidentiality and confirmation of identity, a true trusted infrastructure requires that a trusted authority certify a person or organization as the owner of the keypair. Certificates are special data structures used to register and protectively encapsulate the public-key users and prevent their forgery. A certificate contains the name of a user and its public key. An electronic certificate binds the identity of the person or organization to the key-pair. Certificates also contain the name of the issuer — a certificate authority (CA) — that vouches that the public key in a certificate belongs to the named user. This data, along with a time interval specifying the certificate’s validity, is cryptographically signed by the issuer using the issuer’s private key. The subject and issuer names in certificates are distinguished names (DNs), as defined in the International Telecommunications Union-Telecommunications Standards Sector (ITU-TSS) recommendation X.500 directory services. Such certificates are also called X.509 certificates after the ITUTSS recommendation in which they were defined. The key certificate acts like a kind of electronic identity card. When a recipient uses a sender’s public key to authenticate the sender’s signature (or when the originator uses the recipient’s PKS to encrypt a message or document), the recipient wants to be sure that the sender is who he or she claims to be. The certificate provides that assurance. A certificate could be tied to one individual or represent an organizational authority that in turn represents the entire organization. Also, certificates could represent various levels of assurance — from those dispensed by a machine to those registered with a personally signed application. Additional assurance could be provided by the personal presentation of a signed application along with proof of identity or by the verification of a biometric test (e.g., fingerprint or retina scan) for each use of the private key. Exhibit 25-1 shows a possible scenario for obtaining a certificate. The registration process might work as follows: 300

Exhibit 25-1. The registration process.

Developing a Trusted Infrastructure for Electronic Commerce Services

301

SECURITY • The affiliate (i.e., candidate for certificate) fills out the application, generates private/public key-pairs, and sends for the certificate, enclosing his or her public key. • The organizational authority approves the application. • The organizational authority passes the certificate application to the certification authority. • The certification authority sends back a message confirming receipt of the application. • After proper proofing, the certification authority sends the certificate to the applicant-affiliate. • The applicant-affiliate then loads the certificate to his or her workstation, verifies the certificate authority’s digital signature, and saves a copy of the certificate. Digital Signatures. Exhibit 25-2 illustrates how a digital signature ensures the identity of the message originator. It shows how a message recipient would use an originator’s digital signature to authenticate that originator.

On the Web, authentication could work as follows: • The originator creates a message and the software performs a hash on the document. • The originator’s software then signs the message by encrypting it with the originator’s private key. • The originator sends the message to the server, attaching his or her public key and certificate to the message if necessary. • The server either requests the originator’s public key from a certificate/key repository or extracts the certification from the originator’s message. With this service, the authentication authority could either attach an authentication message verifying the digital signature’s authenticity to the originator’s message or provide that authentication to the recipient via a publicly accessible database. Upon receipt, the recipient would either acknowledge the originator’s authenticity via the attached authentication message or access the public key and certificate from the publicly accessible database to read the signature. To provide such levels of assurance, the certification authority must establish proofing stations where individuals and organizations can present themselves with appropriate identification and apply for certificates. The authority must also maintain or be part of a legal framework of protection and be in a position to mount an enforcement process to protect customers against fraud. 302

Exhibit 25-2. Client authentication.

Developing a Trusted Infrastructure for Electronic Commerce Services

303

SECURITY Certificate Repository The certificate authority also provides the vehicle for the distribution of public keys. Thus, the certificate authority would have to maintain the public-key certificates in a directory server that can be accessed by authorized persons and computers. Exhibit 25-3 shows how subscribers might use such a repository. Certificates could be retrieved on demand along with their current status. Additional information, such as e-mail addresses or fax numbers, could also be available on demand. The repository would work as follows: • The message originator creates a message, generates a digital signature, and sends the message. • The recipient sends a signed message requesting the originator’s public key from the certificate repository. • The certificate repository verifies the requester’s signature and returns the public key to the recipient. The certificate authority could also use the certificate repository to maintain a certificate revocation list (CRL), which provides notification of certificates that are revoked pursuant to a suspected compromise of the private key. This service could also require that the authority report such compromises via a compromised key list to special customers — possibly those enrolled in a subscribed service — and that such notifications be made available to all customers. Finally, transactions involving certificates issued by other certificate authorities require that a cross-certification record be maintained and made publicly available in the certificate repository. Electronic Postmark A service providing an electronic date and time postmark establishes the existence of a message at a specific point in time. By digitally signing the postmark, the postmarking authority assures the communicating parties that the message was sent, was in transit, or was received at the indicated time. This service is most useful when the recipient requires the originator to send a message by a specified deadline. The originator would request the postmark authority to postmark the message. The authority would receive a digest of the message, add a date and time token to it, digitally sign the package, and send it back to the originator, who would forward the complete package (i.e., signed digest, time stamp, and original message) to the recipient, as shown in Exhibit 25-4. 304

Exhibit 25-2. Client authentication.

Developing a Trusted Infrastructure for Electronic Commerce Services

303

Exhibit 25-2. Client authentication.

Developing a Trusted Infrastructure for Electronic Commerce Services

303

Developing a Trusted Infrastructure for Electronic Commerce Services Electronic postmarking functions as follows: • The originator sends a request to the postmark authority to postmark a message or document (i.e., a digital digest of the message or document). • The postmark authority adds date and time to the message received and affixes its digital signature to the entire package. • The postmark authority sends the package back to the originator. • The originator sends the original message or document plus the postmarked package to the recipient. • The recipient verifies the postmark authority signature with the authority’s public key and reads the message or document. Return Receipts This service reports one of three events: a message has transited the network, it has been received at the recipient’s mailbox, or the recipient has actually decoded and opened the message at a specific date and time. In the latter instance, the transaction delivered to the recipient that has been encrypted might be set up only to be decrypted with a special onetime key, as shown in Exhibit 25-5. This one-time key could be provided by the postmark authority upon receipt of an acknowledgment from the recipient, accompanied by the recipient’s digital signature. Here is how return receipt might work: • The originator sends a message digest to the return receipt and postmark authority (the authority) with a request for a postmark and return receipt. • The authority receives the message digest, adds date and time, encrypts the result, attaches a message to the recipient to request the decryption key from the authority upon receipt of the message, and affixes its digital signature to the package. • The authority returns the postmarked, receipted package to the originator, who sends it to the recipient. • The recipient receives the message package and makes a signed request for the decryption key from the authority. • The authority receives the recipient’s request, verifies the recipient’s digital signature, and sends the decryption key to the recipient, who then decrypts and reads the message. • The authority simultaneously forwards the return receipt to the originator. Storage and Retrieval Services These services include transaction archiving where copies of transactions are held for specified periods of time, as illustrated in Exhibit 25-6. The service might also include information (i.e., documents, videos, or business transactions) that can be sealed, postmarked, and held in public storage to 307

Exhibit 25-5. Return receipt.

SECURITY

308

Developing a Trusted Infrastructure for Electronic Commerce Services

Exhibit 25-6.

Storage and retrieval.

be retrieved via any authorized access. Likewise, encrypted information (i.e., documents, videos, or business transactions) can be sealed, postmarked, and further encrypted and held in sealed storage for indefinite periods of time. Each of these storage and retrieval capabilities must carry legal standing and the stamp of authenticity required for electronic correspondents. Storage and retrieval works as follows: • The originator sends a request to the archive to archive a document or message for a specified period of time and designates this information as publicly retrievable. • The archive adds date and time to the message, verifies the identity of the originator, affixes a digital signature to the package, and archives the package. • A customer requests the document from the archive. • The archive retrieves the document, adds a date and time stamp to the package, affixes another digital signature to the new package, and sends it to the recipient. • The recipient verifies the first and second archive signatures and reads the message. 309

SECURITY USE OF THESE COMMERCIAL EXCHANGE SERVICES Electronic commerce services (ECS) can be used in one of three ways: • The originator sends a message to the authority with a request for service, the authority provides the service and returns the message to the originator, and the originator then forwards the message to the recipient. • The originator sends a message to a value-added network (VAN), which then forwards the message to the authority with a request for services. The authority provides the service and returns the message to the VAN, which then forwards the message to the recipient. • The originator sends a message to the authority with a request for service and the address of the recipient. The authority then forwards the message directly to the recipient. All these services could be provided by a single authority, by a hierarchy of authorities, or by a network of authorities, each specializing in one or more of these services. AVAILABLE TECHNOLOGIES FOR ELECTRONIC COMMERCE Currently, three major technologies are capable of providing electronic commerce services — e-mail, the World Wide Web, and open EDI. Typical of advanced technologies, security elements are the last to be developed and yet are essential if these technologies are to be deemed trustworthy for electronic commerce. The issues of confidentiality, confirmation of identity, time certainty, and legal protection apply to all these technologies. The solutions — certification, key repositories, postmarking, return receipts, and storage and retrieval — are equally applicable to each of these technologies. Although the state of universality and interoperability varies among these technologies, they are all in a relative state of immaturity. Secure E-mail Electronic messaging’s most classic manifestation is e-mail. Because of its capacity for handling attachments, e-mail can be used to transfer official business, financial, technical, and a variety of multimedia forms. DMS and PEM. Both the Department of Defense standard for e-mail, which is based on the ITU’s X.400 standard for e-mail (called the Defense Message System or DMS), and the Internet e-mail standard, the Simple Mail Transfer Protocol (SMTP), have made provisions for security. The DMS uses encapsulation techniques at several security levels to encrypt and sign e-mail messages. The security standard for the Internet is called 310

Developing a Trusted Infrastructure for Electronic Commerce Services Privacy Enhanced Mail (PEM). Both methods rely on a certificate hierarchy and known and trusted infrastructure. Neither method is fully developed. Secure World Wide Web The phenomenal growth of the Web makes it a prime candidate for the dissemination of forms and documents. Organizations see the Web as a prime tool for services such as delivery of applications and requests for information. However, Web technology has two competing types of security: one at the application layer that secures HyperText Transfer Protocol (HTTP) formatted data (known as SHTTP), and one at the socket layer that encrypts data in the format in which it is transported across the network. In addition, vendors do not yet support either client-side authentication or the use of X.509 certificates. Although software for such activities as client authentication can be developed relatively quickly, vendors have to be convinced that there is a real market for such products. This technology is about to emerge, and although it will emerge first to support Web applications, it will also speed the development of e-mail and EDI security services. Secure Open EDI Until now, EDI has been used in closed, value-added networks where security and integrity can be closely controlled. Signing and encryption have been proprietary to the EDI product in use or to the value-added EDI network provider. By contrast, open EDI, running across open networks, requires adherence to the standards that are still being developed and a yet-to-be developed infrastructure that can ensure trusted keys. To date, the various schemes to accelerate the use of open systems for EDI have not captured the imagination of EDI users and providers. THE OVERRIDING ISSUE: A PUBLIC KEY CERTIFICATE INFRASTRUCTURE The suite of services and technologies described in this chapter depend on trusted public keys and their bindings to users. Users could be completely assured of the integrity of keys and their bindings if they were exchanged manually. Because business is conducted on a national and international scale, users have to be assured of the integrity of the registration authority and the key repository in an inevitably complex, electronic way. One as-yet-unresolved issue is whether such an authority or authorities should be centralized and hierarchical or distributed. The centralized, hierarchical scheme would mean that certification authorities (and purveyors of the accompanying services) would be certified by a higher 311

SECURITY authority that, in turn, might be certified by yet a higher authority — and so on to the root authority. This kind certification would create a known chain of trust from the highest to the closest certification authority. This scheme is often referred to as the Public Key Infrastructure (PKI). The alternative assumes that the market will foster the creation of a variety of specialized certification authorities to serve communities of interest. A complicated method of cross-referencing and maintaining those cross-references in the certificate repository for each community of interest would then develop. The outcome of this debate is likely to result in a combination of both methods, such as several hierarchies with some kind of managed cross-referencing to enable public-key exchanges between disparate communities of interest when required. Following are some of the issues yet to be resolved: • • • •

agreement on the exact contents of certificates definition of the size of prime numbers used in key generation establishment of the qualifications required for obtaining a certificate definition of the identification and authentication requirements for certificate registration • ruling on the frequency with which certificates are renewed • agreement on the legal standing and precedence for such technology

CONCLUSION Groups such as the Internet Engineering Task Force (IETF), the federal government’s Public Key Infrastructure (PKI) users group, and even the American Bar Association are tackling these knotty issues. In fact, with toolkits now available that allow the user to become his or her own certificate authority, everyone can get into the act. Private companies such as VeriSign are establishing themselves as certification authorities so that users will give their public keys and certificates credence. The National Security Agency wants to become the certificate authority for the federal government. The U.S. Postal Service is intent on offering electronic commerce services to businesses and residences by acting as the certificate authority and provider. An infrastructure will emerge, and it will probably work for users very similar to the way that it has been described in this chapter.

312

Chapter 26

Application-Layer Security Protocols for Networks Bill Stackpole

WE ARE NOT IN KANSAS ANYMORE

THE

INCREDIBLE GROWTH OF INTERNET USAGE HAS SHIFTED ROUTINE

business transactions from fax machine and telephones to e-mail and E-commerce. This shift can be attributed in part to the economical worldwide connectivity of the Internet but also to the Internet capacity for more sophisticated types of transactions. Security professionals must understand the issues and risks associated with these transactions if they want to provide viable and scalable security solutions for Internet commerce. Presence on the Internet makes it possible to conduct international, multiple-party, and multiple-site transactions regardless of time or language differences. This level of connectivity has, however, created a serious security dilemma for commercial enterprises. How can a company maintain transactional compatibility with thousands of different systems and still ensure the confidentiality of those transactions? Security measures once deemed suitable for text-based messaging and file transfers seem wholly inadequate for sophisticated multimedia and E-commerce transfers. Given the complexity of these transactions, even standardized security protocols like IPSec are proving inadequate. This chapter covers three areas that are of particular concern: electronic messaging, World Wide Web (WWW) transactions, and monetary exchanges. All are subject to potential risk of significant financial losses as well as major legal and public relations liabilities. These transactions require security well beyond the capabilities of most lower-layer security protocols. They require application-layer security.

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

313

SECURITY A LAYER-BY-LAYER LOOK AT SECURITY MEASURES Before going into the particulars of application-based security, it may be helpful to look at how security is implemented at the different ISO layers. Exhibit 26-1 depicts the ISO model divided into upper-layer protocols (those associated with the application of data) and lower-layer protocols (those associated with the transmission of data). Examples of some of the security protocols used at each layer are listed on the right. Exhibit 26-1. ISO Seven-Layer Model.

ISO Seven Layer Model 7

Applications

6

Presentation

5

Session

4

Transport

3

Network

2

Data Link

1

Physical

PEM, S-HTTP, SET

SSL IPSEC PPTP, swIPe VPDN, L2F, L2TP Fiber Optics

The following are common methods for providing security at the physical layer (Layer 1): • securing the cabling conduits: encase them in concrete • shielding against spurious emissions: TEMPEST • using media that are difficult to tap: fiber optics While effective, these methods are limited to things within one’s physical control. Common Layer-2 measures include physical address filtering and tunneling (i.e., L2F, L2TP). These measures can be used to control access and provide confidentiality across certain types of connections but are limited to segments where the end-points are well-known to the security implementer. Layer-3 measures provide for more sophisticated filtering and tunneling (i.e., PPTP) techniques. Standardized implementations like IPSec can provide a high degree of security across multiple platforms. However, Layer-3 protocols are ill-suited for multiple-site implementations because they are limited to a single network. Layer-4 transport-based protocols overcome the single network limitation but still lack the sophistication required for multiple-party transactions. Like all lower-layer protocols, transport-based protocols do not interact with the data contained in the 314

Application-Layer Security Protocols for Networks payload, so they are unable to protect against payload corruption or content-based attacks. APPLICATION-LAYER SECURITY: ALS 101 This is precisely the advantage of upper-layer protocols. Applicationbased security has the capability of interpreting and interacting with the information contained in the payload portion of a datagram. Take, for example, the application proxies used in most firewalls for FTP transfers. These proxies have the ability to restrict the use of certain commands even though the commands are contained within the payload portion of the packet. When an FTP transfer is initiated, it sets up a connection for passing commands to the server. The commands one types (e.g., LIST, GET, PASV) are sent to the server in the payload portion of the command packet, as illustrated in Exhibit 26-2. The firewall proxy — because it is applicationbased — has the ability to “look” at these commands and can therefore restrict their use.

Exhibit 26-2.

File Transfer Protocol – Command – Packet

Ethernet Header

Ip Header

Tcp Header

Payload

0040A0…40020A

10.1.2.1…10.2.1.2

FTP (Command)

List…

Lower-layer security protocols like IPSec do not have this capability. They can encrypt the commands for confidentiality and authentication, but they cannot restrict their use. But what exactly is application-layer security? As the name implies, it is security provided by the application program itself. For example, a data warehouse using internally maintained access control lists to limit user access to files, records, or fields is implementing application-based security. Applying security at the application level makes it possible to deal with any number of sophisticated security requirements and accommodate additional requirements as they come along. This scenario works particularly well when all applications are contained on a single host or secure intranet, but it becomes problematic when one attempts to extend its functionality across the Internet to thousands of different systems and applications. Traditionally, security in these environments has been addressed in a proprietary fashion within the applications themselves, but this is rapidly changing. The distributed nature of applications on the Internet has given rise to several standardized solutions designed to replace these ad hoc, vendor-specific security mechanisms. 315

SECURITY INTEROPERABILITY: THE KEY TO SUCCESS FOR ALS Interoperability is crucial to the success of any protocol used on the Internet. Adherence to standards is crucial to interoperability. Although the ALS protocols discussed in this chapter cover three distinctly different areas, they are all based on a common set of standards and provide similar security services. This section introduces some of these common elements. Not all common elements are included, nor are all those covered found in every ALS implementation, but there is sufficient commonality to warrant their inclusion. Cryptography is the key component of all modern security protocols. However, the management of cryptographic keys has in the past been a major deterrent to its use in open environments like the Internet. With the advent of digital certificates and public-key management standards, this deterrent has been largely overcome. Standards like the Internet Public Key Infrastructure X.509 (pkix) and the Simple Public Key Infrastructure (spki) provide the mechanisms necessary to issue, manage, and validate cryptographic keys across multiple domains and platforms. All of the protocols discussed in this chapter support the use of this Public Key Infrastructure. Standard Security Services: Maximum Message Protection All the ALS protocols covered in this chapter provided these four standard security services: • Confidentiality (a.k.a privacy): the assurance that only the intended recipient can read the contents of the information sent to them. • Integrity: the guarantee that the information received is exactly the same as the information that was sent. • Authentication: the guarantee that the sender of a message or transmission is really who he or she claims to be. • Nonrepudiation: the proof that a message was sent by its originator even if the originator claims it was not. Each of these services relies on a form of cryptography for its functionality. Although the service implementations may vary, they all use a fairly standard set of algorithms. Algorithms Tried and True The strength of a cryptographic algorithm can be measured by its longevity. Good algorithms continue to demonstrate high cryptographic strength after years of analysis and attack. The ALS protocols discussed here support three types of cryptography — symmetric, asymmetric, and hashing — using time-tested algorithms. 316

Application-Layer Security Protocols for Networks Symmetric (also called secret key) cryptography is primarily used for confidentiality functions because it has high cryptographic strength and can process large volumes of data quickly. In ALS implementations, DES is the most commonly supported symmetric algorithm. Asymmetric or publickey cryptography is most commonly used in ALS applications to provide confidentiality during the initialization or set-up portion of a transaction. Public keys and digital certificates are used to authenticate the participating parties to one another and exchange the symmetric keys used for remainder of the transaction. The most commonly supported asymmetric algorithm in ALS implementations is RSA. Cryptographic hashing is used to provide integrity and authentication in ALS implementations. When used separately, authentication validates the sender and the integrity of the message, but using them in combination provides proof that the message was not forged and therefore cannot be refuted (nonrepudiation). The three most commonly used hashes in ALS applications are MD2, MD5, and SHA. In addition to a common set of algorithms, systems wishing to interoperate in an open environment must be able to negotiate and validate a common set of security parameters. The next section introduces some of the standards used to define and validate these parameters. Standardized Gibberish Is Still Gibberish! For applications to effectively exchange information, they must agree upon a common format for that information. Security services, if they are to be trustworthy, require all parties to function in unison. Communication parameters must be established, security services, modes, and algorithms agreed upon, and cryptographic keys exchanged and validated. To facilitate these processes, the ALS protocols covered in this chapter support the following formatting standards: • X.509: The X.509 standard defines the format of digital certificates used by certification authorities to validate public encryption keys. • PKCS: The Public Key Cryptography Standard defines the underlying parameters (object identifiers) used to perform the cryptographic transforms and to validate keying data. • CMS: The Cryptographic Message Syntax defines the transmission formats and cryptographic content types used by the security services. CMS defines six cryptographic content types ranging from no security to signed and encrypted content. They are data, signedData, envelopedData, signedAndEnvelopedData, digestData, and encryptedData. • MOSS: The MIME Object Security Services defines two additional cryptographic content types for multipart MIME (Multimedia Internet 317

SECURITY Mail Extensions) objects that can be used singly or in combination. They are multipart-signed and multipart-encrypted. Encryption is necessary to ensure transaction confidentiality and integrity on open networks, and the Public Key/Certification Authority architecture provides the infrastructure necessary to manage the distribution and validation of cryptographic keys. Security mechanisms at all levels now have a standard method for initiating secure transactions, thus eliminating the need for proprietary solutions to handle secure multiple-party, multiple-site, or international transactions. A case in point is the new SET credit card transaction protocol. SETTING THE EXAMPLE: VISA’S SECURE ELECTRONIC TRANSACTION PROTOCOL SET (Secure Electronic Transaction) is an application-based security protocol jointly developed by Visa and MasterCard. It was created to provide secure payment card transactions over open networks. SET is the electronic equivalent of a face-to-face or mail-order credit card transaction. It provides confidentially and integrity for payment transmissions and authenticates all parties involved in the transaction. Walk through a SET transaction to see how this application-layer protocol handles a sophisticated multi-party financial transaction. A SET transaction involves five different participants: the cardholder, the issuer of the payment card, the merchant, the acquirer that holds the merchant’s account, and a payment gateway that processes SET transactions on behalf of the acquirer. The policies governing how transactions are conducted are established by a sixth party, the brand (i.e., Visa), but they do not participate in payment transactions. A SET transaction requires two pairs of asymmetric encryption keys and two digital certificates: one for exchanging information and the other for digital signatures. The keys and certificates can be stored on a “smart” credit card or embedded into any SET-enabled application (i.e., Web browser). The keys and certificates are issued to the cardholder by a certification authority (CA) on behalf of the issuer. The merchant’s keys and digital certificates are issued to them by a CA on behalf of the acquirer. They provide assurance that the merchant has a valid account with the acquirer. The cardholder and merchant certificates are digitally signed by the issuing financial institution to ensure their authenticity and to prevent them from being fraudulently altered. One interesting feature of this arrangement is that the cardholder’s certificate does not contain his account number or expiration date. That information is encoded using a 318

Application-Layer Security Protocols for Networks secret key that is only supplied to the payment gateway during the payment authorization. Knowing all the players, one can get started. Step 1 The cardholder goes shopping, selects his merchandise, and sends a purchase order to the merchant requesting a SET payment type. (The SET specification does not define how shopping is accomplished, so it has no involvement in this portion of the transaction.) The cardholder and merchant, if they have not already, authenticate themselves to each other by exchanging certificates and digital signatures. During this exchange, the merchant also supplies the payment gateway’s certificate and digital signature information to the cardholder. One will see later how this is used. Also established in this exchange is a pair of randomly generated symmetric keys that will be used to encrypt the remaining cardholder–merchant transmissions. Step 2 Once the above exchanges have been completed, the merchant contacts the payment gateway. Part of this exchange includes language selection information to ensure international interoperability. Once again, certificate and digital signature information is used to authenticate the merchant to the gateway and establish random symmetric keys. Payment information (PI) is then forwarded to the gateway for payment authorization. Notice that only the payment information is forwarded. This is done to satisfy regulatory requirements regarding the use of strong encryption. Generally, the use of strong cryptography by financial institutions is not restricted if the transactions only contain monetary values. Step 3 Upon receipt of the PI, the payment gateway authenticates the cardholder. Notice that the cardholder is authenticated without contacting the purchase gateway directly. This is done through a process called dual-digital signature. The information required by the purchase gateway to authenticate the cardholder is sent to the merchant with a different digital signature than the one used for merchant–cardholder exchanges. This is possible because the merchant sent the purchase gateway certificates to the cardholder in an earlier exchange! The merchant simply forwards this information to the payment gateway as part of the payment authorization request. Another piece of information passed in this exchange is the secret key the gateway needs to decrypt the cardholder’s account number and expiration date. 319

SECURITY Step 4 The gateway reformats the payment information and forwards it via a private circuit to the issuer for authorization. When the issuer authorizes the transaction, the payment gateway notifies the merchant, who notifies the cardholder, and the transaction is complete. Step 5 The merchant finalizes the transaction by issuing a Payment Capture request to the payment gateway, causing the cardholder’s account to be debited, and the merchant’s account to be credited for the transaction amount. A single SET transaction like the one outlined above is incredibly complex, requiring more than 59 different actions to take place successfully. Such complexity requires application-layer technology to be managed effectively. The beauty of SET, however, is its ability to do just that in a secure and ubiquitous manner. Other protocols are achieving similar success in different application areas. FROM POSTCARDS TO LETTERS: SECURING ELECTRONIC MESSAGES Electronic messaging is a world of postcards. As messages move from source to destination they are openly available (like writing on a postcard) to be read by those handling them. If postcards are not suitable for business communications, it stands to reason that electronic mail on an open network is not either. Standard business communications require confidentiality, and other more sensitive communications require additional safeguards like proof of delivery or sender verification, features that are not available in the commonly used Internet mail protocols. This has led to the development of several security-enhanced messaging protocols. PEM is one such protocol. Privacy Enhanced Mail (PEM) is an application-layer security protocol developed by the IETF (Internet Engineering Task Force) to add confidentiality and authentication services to electronic messages on the Internet. The goal was to create a standard that could be implemented on any host, be compatible with existing mail systems, support standard key management schemes, protect both individually addressed and list-addressed mail, and not interfere with nonsecure mail delivery. When the standard was finalized in 1993, it had succeeded on all counts. PEM supports all four standard security services, although all services are not necessarily part of every message. PEM messages can be MIC-CLEAR messages that provide integrity and authentication only; MIC-ONLY messages that provide integrity and authentication with support for certain gateway implementations; 320

Application-Layer Security Protocols for Networks or ENCRYPTED messages that provide integrity, authentication, and confidentiality. Key features of PEM include: • End-to-end confidentiality: Messages are protected against disclosure from the time they leave the sender’s system until they are read by the recipient. • Sender and forwarder authentication: PEM digital signatures authenticate both senders and forwarders and ensure message integrity. PEM utilizes an integrity check that allows messages to be received in any order and still be verified: an important feature in environments like the Internet where messages can be fragmented during transit. • Originator nonrepudiation: This feature authenticates the originator of a PEM message. It is particularly useful for forwarded messages because a PEM digital signature only authenticates the last sender. Nonrepudiation verifies the originator no matter how many times the message is forwarded. • Algorithm independence: PEM was designed to easily accommodate new cryptographic and key management schemes. Currently, PEM supports common algorithms in four areas: DES for data encryption, DES and RSA for key management, RSA for message integrity, and RSA for digital signatures. • PKIX support: PEM fully supports interoperability on open networks using the Internet Public Key Infrastructure X.509. • Delivery system independence: PEM achieves delivery-system independence because its functions are contained in the body of a standard message and use a standard character set, as illustrated in Exhibit 26-3. • X.500 distinguished name support: PEM uses the distinguished name (DN) feature of the X.500 directory standard to identify senders and recipients. This feature separates mail from specific individuals, allowing organizations, lists, and systems to send and receive PEM messages. RIPEM (Riordan’s Internet Privacy Enhanced Mail) is a public domain implementation of the PEM protocol, although not in its entirety. Since the author, Mark Riordan, placed the code in the public domain, it has been ported to a large number of operating systems. Source and binaries are available via FTP to U.S. and Canadian citizens from ripem.msu.edu. Read the GETTING_ACCESS file in the /pub/crypt/ directory before attempting any downloads. Secure/Multipurpose Internet Mail Extensions (S/MIME) is another application-layer protocol that provides all four standard security services 321

322

PEM mail header

PEM message body

Exhibit 26-3. Privacy-enhanced mail.

---- END PRIVACY-ENHANCED MESSAGE ----

jWEnbsewcnbyyrGFe/aa0Tu6EW9s1/CeeRK

kilDsm/jki+kdaj=4HErpalW23yrzmXQjfyumvssdjeiPlamDDL

---- BEGIN PRIVACY-ENHANCED MESSAGE ---Proc-Type: 4, ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC, FA244DE5332B217D Originator-ID-Symmetric: [email protected] Recipient-ID-Symmetric: [email protected] Key-Info: DES-ECB,RSA-MD2,67AB3AAE4338612F, 123456789012345678901234567890AA

From: Bill Stackpole <[email protected]> To: Bill Stackpole <[email protected]> Subject: PEM Demonstration Date: Thu, 17 Dec 1998 18:04:45 -0800 Reply-To: [email protected] X-UIDL: df2342b9646226ab0de0af9d152c267c

SMTP message body

SMTP mail header

SECURITY

Application-Layer Security Protocols for Networks for electronic messages. Originally designed by RSA Data Security, the S/MIME specification is currently managed by the IETF S/MIME Working Group. Although S/MIME is not an IETF standard, it has already garnered considerable vendor support, largely because it is based on well-proven standards that provide a high degree of interoperability. Most notable is, of course, the popular and widely used MIME standard, but S/MIME also utilizes the CMS, PKCS, and X.509 standards. Like PEM, S/MIME is compatible with most existing Internet mail systems and does not interfere with the delivery of nonsecure messages. However, S/MIME has the added benefit of working seamlessly with other MIME transports (i.e., HTTP) and can even function in mixed-transport environments. This makes it particularly attractive for use with automated transfers like EDI and Internet FAX. There are two S/MIME message types: signed, and signed and enveloped. Signed messages provide integrity and sender authentication, while signed and enveloped messages provide integrity, authentication, and confidentiality. The remaining features of S/MIME are very similar to PEM and do not warrant repeating here. A list of commercial S/MIME products that have successfully completed S/MIME interoperability testing is available on the RSA Data Security Web site at: www.rsa.com/smime/html/interop_center.html. A public domain version of S/MIME written in Perl by Ralph Levien is available at: www.c2.org/~raph/premail.html. Open Pretty Good Privacy (OpenPGP), sometimes called PGP/MIME, is another emerging ALS protocol on track to becoming an IETF standard. It is based on PGP, the most widely deployed message security program on the Internet. OpenPGP is very similar in feature and functionality to S/MIME, but the two are not interoperable because they use slightly different encryption algorithms and MIME encapsulations. A list of PGP implementations and other OpenPGP information is available at: http://www-ns.rutgers.edu/~mione/openpgp/. Freeware implementations of OpenPGP are available at the North American Cryptography Archives (www.cryptography.org). TAMING HTTP: WEB APPLICATION SECURITY Web-based applications are quickly becoming the standard for all types of electronic transactions because they are easy to use and highly interoperable. These features are also their major security failing. Web transactions traverse the network in well-known and easily intercepted formats, making them quite unsuitable for most business transactions. This section covers some of the mechanisms used to overcome these Web security issues. 323

SECURITY Secure HyperText Transfer Protocol (S/HTTP) is a message-oriented security protocol designed to provide end-to-end confidentiality, integrity, authentication, and nonrepudiation services for HTTP clients and servers. It was originally developed by Enterprise Integration Technologies (now Verifone, Inc.) in 1995. At this writing, S/HTTP is still an IETF draft standard, but it is already widely used in Web applications. Its success can be attributed to a flexible design that is rooted in established standards. The prominent standard is, of course, HTTP, but the protocol also utilizes the NIST Digital Signature Standard (DSS), CMS, MOSS, and X.509 standards. S/HTTP’s strict adherence to the HTTP messaging model provides delivery-system independence and makes it easy to integrate S/HTTP functions into standard HTTP applications. Algorithm independence and the ability to negotiate security options between participating parties assures S/HTTP’s interoperability for years to come. Secure HTTP modes of operation include message protection, key management, and a transaction freshness mechanism. Secure HTTP protection features include the following: • Support for MOSS and CMS: Protections are provided in both content domains using the CMS “application/s-http” content-type or the MOSS “multipart-signed” or “multipart-encrypted” header. • Syntax compatibility: Protection parameters are specified by extending the range of HTTP message headers, making S/HTTP messages syntactically the same as standard HTTP messages — except the range of the headers is different and the body is usually encrypted. • Recursive protections: Protections can be used singly or applied one layer after another to achieve higher levels of protection. Layering the protections makes it easier for the receiving system to parse them. The message is simply parsed one protection at a time until it yields a standard HTTP content type. • Algorithm independence: The S/HTTP message structure can easily incorporate new cryptographic implementations. The current specification requires supporting MD5 for message digests, MD5-HMAC for authentication, DES-CBC for symmetric encryption, and NIST-DSS for signature generation and verification. • Freshness feature: S/HTTP uses a simple challenge–response to ensure that the data being returned to the server is “fresh.” In environments like HTTP, where long periods of time can pass between messages, it is difficult to track the state of a transaction. To overcome this problem, the originator of an HTTP message sends a freshness value (nonce) to the recipient along with the transaction data. The recipient returns the nonce with a response. If the nonces match, the data is fresh, and the transaction can continue. Stale data indicates an error condition. 324

Application-Layer Security Protocols for Networks Secure HTTP key management modes include: • Manual exchange: Shared secrets are exchanged through a simple password mechanism like PAP. The server simply sends the client a dialog box requesting a userid and password then authenticates the response against an existing list of authorized users. • Public key exchange: Keys are exchanged using the Internet Public Key Infrastructure with full X.509 certificate support. S/HTTP implementations are required to support Diffie-Hellman for in-band key exchanges. • Out-of-band key exchange: Symmetric keys can be prearranged through some other media (i.e., snail mail). This feature, unique to the S/HTTP, permits parties that do not have established public keys to participate in secure transactions. • In-band symmetric key exchange: S/HTTP can use public-key encryption to exchange random symmetric keys in instances where the transaction would benefit from the higher performance of symmetric encryption. Many commercial Web browsers and servers implement the S/HTTP protocol, but the author was unable to find any public domain implementations. A full implementation of S/HTTP including the C source code is available in the SecureWeb Toolkit™ from Terisa (www.spyrus.com). The kit also contains the source code for SSL. Secure Socket Layer (SSL) is a client/server protocol designed by Netscape to provide secure communications for its Web browser and server products. It was quickly adopted by other vendors and has become the de facto standard for secure Web transactions. However, SSL is not limited to Web services; it can provide confidentiality, integrity, authentication, and nonrepudiation services between any two communicating applications. While included here as an application-layer protocol, SSL is actually designed to function at the session and application layers. The SSL Record Protocol provides security services at the session layer — the point where the application interfaces to the TCP/IP transport sockets. It is used to encapsulate higher-layer protocols and data for compression and transmission. The SSL Handshake Protocol is an application-based service used to authenticate the client and server to each other and negotiate the security parameters for each communication session. The SSL Handshake Protocol utilizes public-key encryption with X.509 certificate validation to negotiate the symmetric encryption parameters used for each client/server session. SSL is a stateful protocol. It transitions through several different states during connection and session operations. The handshake protocol is used to coordinate and maintain these states. 325

SECURITY One SSL session may include multiple connections, and participating parties may have multiple simultaneous sessions. The session state maintains the peer certificate information, compression parameters, cipher parameters, and the symmetric encryption key. The connection state maintains the MAC and asymmetric keys for the client and server, as well as the vectors (if required) for symmetric encryption initialization. SSL was designed to be fully extensible and can support multiple encryption schemes. The current version requires support for these schemes: • • • • •

DES, RC2, RC4, and IDEA for confidentiality RSA and DSS for peer authentication SHA and MD5 for message integrity X.509 and FORTEZZA certificates for key validation RSA, Diffie–Hellman, and FORTEZZA for key exchange

SSL also supports NULL parameters for unsigned and unencrypted transmissions. This allows the implementer to apply an appropriate amount of security to his application. The support for the FORTEZZA hardware encryption system is unique to the SSL, as is the data compression requirement. SSL uses a session caching mechanism to facilitate setting up multiple sessions between clients and servers and resuming disrupted sessions. There is an exceptional public domain implementation of SSL created by Eric Young and Tim Hudson of Australia called SSLeay. It includes a full implementation of Netscape’s SSL Version 2 with patches for Telnet, FTP, Mosaic, and several Web servers. The current version is available from the SSLeay Web site at www.ssleay.org. The site includes several SSL white papers and an excellent Programmers’ Reference. “DON’T SHOW ME THE MONEY”: MONETARY TRANSACTION SECURITY The success of commerce on the Internet depends on its ability to conduct monetary transactions securely. Although purchasing seems to dominate this arena, bill payment, fund and instrument transfers, and EDI are important considerations. The lack of standards for electronic payment has fostered a multitude of proprietary solutions, including popular offerings from Cybercash (Cybercoin), Digital (Millicent), and Digicash. However, proprietary solutions are not likely to receive widespread success in a heterogeneous environment like the Internet. This section will concentrates on standardized solutions. Because the SET protocol has been covered in some detail already, only SET implementations are mentioned here. Secure Payment (S/PAY) is a developer’s toolkit based on the SET protocol. It was developed by RSA Data Security, although the marketing rights currently belong to the Trintech Group (www.trintech.com). The S/PAY 326

Application-Layer Security Protocols for Networks library fully implements the SET v1.0 cardholder, merchant, and acquirer functions and the underlying encryption and certificate management functions for Windows95/NT and major UNIX platforms. Included in the code is support for hardware-based encryption engines, smart card devices, and long-term private key storage. Trintech also offers full implementations of SET merchant, cardholder, and acquirer software. This includes their PayWare Net-POS product, which supports several combinations of SSL and SET technologies aimed at easing the transition from Web SSL transactions to fully implemented SET transactions. Open Financial Exchange (OFX) is an application-layer protocol created by Checkfree, Intuit, and Microsoft to support a wide range of consumer and small-business banking services over the Internet. OFX is an open specification available to any financial institution or vendor desiring to implement OFX services. OFX uses SSL with digital certificate support to provide confidentiality, integrity, and authentication services to its transactions. The protocol has gained considerable support in the banking and investment industry because it supports just about every conceivable financial transaction. Currently, the OFX committee is seeking to expand OFX’s presence through interoperability deals with IBM and other vendors. Copies of the OFX specification are available from the Open Financial Exchange Web site (www.ofx.net). Micro Payment Transfer Protocol (MPTP) is part of The World Wide Web Consortium (W3C) Joint Electronic Payment Initiative. Currently, MPTP is a W3C working draft. The specification is based on variations of Rivest and Shamir’s Pay-Word, Digital’s Millicent, and Bellare’s iKP proposals. MPTP is a very flexible protocol that can be layered upon existing transports like HTTP or MIME to provide greater transaction scope. It is highly tolerant of transmission delays, allowing much of the transaction processing to take place offline. MPTP is designed to provide payments through the services of a third-party broker. In the current version, the broker must be common to both the customer and the vendor, although inter-broker transfers are planned for future implementations. This will be necessary if MPTP is going to scale effectively to meet Internet demands. Customers establish an account with a broker. Once established, they are free to purchase from any vendor common to their broker. The MPTP design takes into consideration the majority of risks associated with electronic payment and provides mechanisms to mitigate those risks, but it does not implement a specific security policy. Brokers are free to define policies that best suit their business requirements. MPTP relies on S/Key technology using MD5 or SHA algorithms to authorize payments. MPTP permits the signing of messages for authentication, integrity, and nonrepudiation using public or secret key cryptography and 327

SECURITY fully supports X.509 certificates. Although MPTP is still in the draft stages, its exceptional design, flexibility, and high performance destine it to be a prime contender in the electronic payment arena. Java Electronic Commerce Framework (JECF) is the final item of discussion. JECF is not an application protocol. It is a framework for implementing electronic payment processing using active-content technology. Active-content technology uses an engine (i.e., a Java virtual machine) installed on the client to execute program components (e.g., applets) sent to it from the server. Current JECF active-content components include the Java Commerce Messages, Gateway Security Model, Commerce JavaBeans, and Java Commerce Client (JCC). JECF is based around the concept of an electronic wallet. The wallet is an extensible client-side mechanism capable of supporting any number of E-commerce transactions. Vendors create Java applications consisting of service modules (applets) called Commerce JavaBeans that plug into the wallet. These applets implement the operations and protocols (i.e., SET) necessary to conduct transactions with the vendor. There are several significant advantages of this architecture: • Vendors are not tied to specific policies for their transactions. They are free to create modules containing policies and procedures best suited to their business. • Clients are not required to have specialized applications. Since JavaBean applets are active content, they can be delivered and dynamically loaded on the customer’s system as the transaction is taking place. • Applications can be updated dynamically. Transaction applets can be updated or changed to correct problems or meet growing business needs without having to send updates to all the clients. The new modules will be loaded over the old during their next transaction. • Modules can be loaded or unloaded on-the-fly to accommodate different payment, encryption, or language requirements. OFX modules can be loaded for banking transactions and later unloaded when the customer requires SET modules to make a credit card purchase. • JavaBean modules run on any operating system, browser, or application supporting Java. This gives vendors immediate access to the largest possible customer base. The flexibility, portability, and large Java user-base make the Java Electronic Commerce Framework (JECF) a very attractive E-commerce solution. It is sure to become a major player in the electronic commerce arena.

328

Application-Layer Security Protocols for Networks IF IT IS NOT ENCRYPTED NOW… The Internet has dramatically changed the way people do business, but that has not come without a price. Security for Internet transactions and messaging is woefully lacking, making much of what people are doing on the Internet an open book for all to read. This cannot continue. Despite the complexity of the problems in existence today, there are solutions. The technologies outlined in this chapter provide real solutions for mitigating Internet business risks; one can secure messages, Web applications, and monetary exchanges. Admittedly, some of these applications are not as polished as one would like, and some are difficult to implement and manage, but they are nonetheless effective and most certainly a step in the right direction. Someday, all business transactions on the Internet will be encrypted, signed, sealed, and delivered, but can one wait for that day? Business transactions on the Internet are increasing, and new business uses for the Internet are going to be found. Waiting for things to get better is only going to put us further behind the curve. Someone has let the Internet bull out of the cage — and we are either going to take him by the horns or get run over! ALS now! Bibliography Crocker, S., Freed, N., Galvan, J., and Murphy, S., RFC 1848 — MIME object security services, IETF, October 1995. Dusse, Steve and Matthews, Tim, S/MIME: anatomy of a secure e-mail standard, Messaging Magazine, 1998. Freier, Alan O., Karlton, Philip, and Kocher, Paul C., INTERNET-DRAFT — The SSL Protocol Version 3.0, November 18, 1996. Hallam-Baker, Phillip, Micro Payment Transfer Protocol (MPTP) Version 1.0, Joint Electronic Payment Initiative — W3C, November 1995. Hirsch, Frederick, Introducing SSL and certificates using SSLeay, the Open Group Research Institute, World Wide Web Journal, Summer 1997. Hudson, T.J. and Young, E.A., SSL Programmers Reference, July 1, 1995. Lundblade, Laurence, A Review of E-mail Security Standards, Qualcomm Inc., 1998. Pearah, David, Micropayments, Massachusetts Institute of Technology, April 23, 1997. PKCS #7: Cryptographic Message Syntax Standard, RSA Laboratories Technical Note Version 1.5, RSA Laboratories, November 1, 1993. Ramsdell, Blake, INTERNET-DRAFT — S/MIME Version 3 Message Specification, Worldtalk Inc., August 6, 1998. Resorla, E. and Schiffman, A., INTERNET-DRAFT — The Secure HyperText Transfer Protocol, Terisa Systems, Inc., June 1998. Schneier, Bruce, E-Mail Security: How to Keep Your Electronic Messages Private, John Wiley & Sons, New York, 1995. SET Secure Electronic Transaction Specification, Book 1: Business Description, Setco, Inc., May 31, 1997.

329

SECURITY Resources E-Payments Resource Center, Trintech Inc., www.trintech.com Information Society Project Office (ISPO), www.ispo.cec.be Java Commerce Products, http://java.sun.com SET Reference Implementation (SETREF), Terisa Inc., www.terisa.com SET — Secure Electronic Transaction LLC, www.setco.org S/MIME Central, http://www.rsa.com/smime/ The Electronic Messaging Association, www.ema.org The Internet Mail Consortium (IMC), www.inc.org Transaction Net and the Open Financial Exchange, www.ofx.net

330

Chapter 27

Security of Communication Protocols and Services William H. Murray

THE

INFORMATION SECURITY MANAGER IS CONFRONTED WITH A WIDE

variety of communications protocols and services. At one level, the IS manager would like to be able to ignore how the information gets from one place to another — and he would like to be able to assume security. At another, he understands that he has only limited control over how the information moves; because the user may be able to influence the choice of path, the manager prefers not to rely on it. However, that being said, the manager also knows that there are differences in the security properties of the various protocols and services that may otherwise be found useful. This chapter describes the popular protocols and services, talks about their intended uses and applications, and describes their security properties and characteristics. It compares and contrasts similar protocols and services, makes recommendations for their use, and also recommends compensating controls or alternatives for increasing security. INTRODUCTION For the last century, people have trusted the dial-switched voice-analog network. It was operated by one of the most trusted enterprises in the history of the world. It was connection-switched and point-to-point. While there was some eavesdropping, most of it was initiated by law enforcement and was, for the most part, legitimate. While a few people carefully considered what they would say, most used the telephone automatically and without worrying about being overheard. Similarly, people were able to

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

331

SECURITY recognize most of the people who called; they trusted the millions of copies of the printed directories; and trusted the network to connect only to the number dialed. While it is not completely justified, much of that automatic trust has been transferred to the modern digital network and even to the Internet. All other things being equal, the IS managers would like to be able to ignore how information moves from one place to another, and would like to be able to assume that they can put it into a pipe at point A and have it come out reliably only at B. Of course, in the real world of the modern integrated network, this is not the case. In this world, the traffic is vulnerable to eavesdropping, misdirection, interference, contamination, alteration, and even total loss. On the other hand, relatively little of this happens; the vast majority of information is delivered when and how it is intended and without any compromise. This happens in part despite the way the information is moved and in part because of how it is moved. The various protocols and services have different security properties and qualities. Some provide error detection, corrective action such as retransmission, error correction, guaranteed delivery, and even information hiding. The different levels of service exist because they have different costs and performance. They exist because different traffic, applications, and environments have different requirements. For example, the transfer of a program file has a requirement for bit-for-bit integrity; in some cases, if one loses a bit, it is as bad as losing the whole file. On the other hand, a few seconds, or even tens of seconds, of delay in the transfer of the file may have little impact. However, if one is moving voice traffic, the loss of tens of bits may be perfectly acceptable, while delay in seconds is intolerable. These costs must be balanced against the requirements of the application and the environment. While the balance between performance and cost is often struck without regard to security, the reality is that there are security differences. The balance between performance, cost, and security is the province of the IS manager. Therefore, the manager needs to understand the properties and characteristics of the protocols so that the necessary trade-offs can be made or those that have already been made, can be evaluated. Finally, all protocols have limitations and many have fundamental vulnerabilities. Implementations of protocols can compensate for such vulnerabilities only in part. Implementers may be faced with hard design choices, and they may make errors resulting in implementation-induced

332

Security of Communication Protocols and Services vulnerabilities. The IS manager must understand these vulnerabilities to be able to know when and how to compensate. PROTOCOLS A protocol is an agreed-upon set of rules or conventions for communicating between two or more parties. “Hello” and “goodbye” for beginning and ending voice phone calls are examples of a simple protocol. A slightly more sophisticated protocol might include lines that begin with tags like “This is (name) calling.” Protocols are to codes as sentences and paragraphs are to words. In a protocol, the parties may agree to addressing, codes, format, packet size, speed, message order, error detection and correction, acknowledgments, key exchange, and other things. This chapter deals with a number of common protocols, and describes their intended use or application, characteristics, design choices, and limitations. INTERNET PROTOCOL The Internet Protocol (IP) is a primitive and application-independent protocol for addressing and routing packets of data within a network. It is the “IP” in TCP/IP, the protocol suite that is used in and defines the Internet. It is intended for use in a relatively flat, mesh, broadcast, connectionless, packet-switched network like the Internet. IP is analogous to a postcard in the eighteenth century. The sender wrote the message on one side of the card and the address and return address on the other. The sender then gave it to someone who was going in the general direction of the intended recipient. The message was not confidential; everyone who handled it could read it and might even make an undetected change to it. IP is a “best-efforts” protocol; it does not guarantee message delivery nor provide any evidence as to whether or not the message was delivered. It is unchecked; the receiver does not know (whether or not he received the entire intended message or whether or not it is correct). The addresses are unreliable; the sender cannot be sure that the message will go only where intended — or even when intended. The receiver cannot be sure that the message came from the address specified as the return address in the packet.

333

SECURITY The protocol does not provide any checking or hiding. If the application requires these, they must be implied or specified someplace else — usually in a higher (i.e., closer to the application) protocol layer. IP specifies the addresses of the sending or receiving hardware device,1 but if that device supports multiple applications, IP does not specify which of those it is intended for. The IP protocol uses 32-bit addresses. However, the use or meaning of the bits within the address depends on the size and use of the network. Addresses are divided into five classes. Each class represents a different design choice between the number of networks and the number of addressable devices within the class. Class A addresses are used for very large networks where the number of such networks is expected to be low but the number of addressable devices is expected to be very high. Class A addresses are used for nation states and other very large domains such as .mil, .gov, and .com. As shown in Exhibit 27-1, a zero in bit position 0 of an address specifies it as a class A address. Positions 1 through 7 are used to specify the network, and positions 8 through 31 are used to specify devices within the network. Class C is used for networks where the possible number of networks is expected to be high but the number of addressable devices in each net is less than 128. Thus, in general, class B is used for enterprises, states, provinces, or municipalities, and class C is used for LANs. Class D is used for multicasting, and Class E is reserved for future uses. One will often see IP addresses written as nnn.nnn.nnn.nnn. Exhibit 27-1. IP Network Address Formats. Network Class A B C D E

Description National Enterprise LAN Multicast Reserved

Address Class 0 in bit 0 10 in bits 0–1 110 in 0–2 1110 in 0–3 1111 in 0–3

Network Address

Device Address

1–7 2–15 3–23 4–31

8–31 16–31 24–31

While security is certainly not IP’s long suit, it is responsible for much of the success of the Internet. It is fast and simple. In practice, the security limitations of IP simply do not matter much. Applications rely on higherlevel protocols for security.

1. There is a convention of referring to all network addressable devices as “hosts.” Such usage in other documents equates to the use of device or addressable device here. IPv6 defines “host.”

334

Security of Communication Protocols and Services Internet Protocol v6.0 (IPng) IPv6 (or “next generation”) is a backwardly compatible new version of IP. It is intended to permit the Internet to grow, both in terms of the number of addressable devices, particularly class A addresses, and in quantity of traffic. It expands the address to 128 bits, simplifies the format header, improves the support for extensions and options, adds a “quality-of-service” capability, and adds address authentication and message confidentiality and integrity. IPv6 also formalizes the concepts of packet, node, router, host, link, and neighbors that were only loosely defined in v4. In other words, IPng addresses most of the limitations of IP, specifically including the security limitations. It provides for the use of encryption to ensure that information goes only where it is intended to go. This is called secure-IP. Secure-IP can be used for point-to-point security across an arbitrary network. More often, it is used to carve virtual private networks (VPNs) or secure virtual networks (SVNs)2 out of such arbitrary networks. Many of the implementations of secure-IP are still proprietary and do not guarantee interoperability with all other such implementations. User Datagram Protocol (UDP) The UDP protocol is similar to IP in that it is connectionless and offers “best-effort” delivery service, and it is similar to TCP in that it is both checked and application specific. Exhibit 27-2 shows the format of the UDP datagram. Unless the UDP source port is on the same device as the destination port, the UDP packet will be encapsulated in an IP packet. The IP address will specify the physical device, while the UDP address will specify the logical port or application on the device. Exhibit 27-2. UDP Datagram. Bit Positions

Usage

0–15 16–31 32–47 48–63 64–n

Source port address Destination port address Message length (n) Checksum Data

2. VPN is used here to refer to the use of encryption to connect private networks across the public network, gateway-to-gateway. SVN is used to refer to the use of encryption to talk securely, end-to-end, across arbitrary networks. While the term “VPN” is sometimes used to describe both applications, different implementations of secure-IP may be required for the two applications.

335

SECURITY UDP implements the abstraction of “port,” a named logical connection or interface to a specific application or service within a device. Ports are identified by a positive integer. Port identity is local to a device; that is, the use or meaning of port number is not global. A given port number can refer to any application that the sender and receiver agree upon. However, by convention and repeated use, certain port numbers have become identified with certain applications. Exhibit 27-3 lists examples of some of these conventional port assignments. Exhibit 27-3. Sample UDP Ports. Port Number 23 53 43 69 80 119 137 138 139

Application Telnet DNS TFTP HTTP Net News

Description Domain name service Whois Trivial file transfer service Web service Netbios name service Netbios datagrams Netbios session data

Transmission Control Protocol (TCP) TCP is a sophisticated composition of IP that compensates for many of its limitations. It is a connection-oriented protocol that enables two applications to exchange streams of data synchronously and simultaneously in both directions. It guarantees both the delivery and order of the packets. Because packets are given a sequence number, missing packets will be detected, and packets can be delivered in the same order in which they were sent; lost packets can be automatically resent. TCP also adapts to the latency of the network. It uses control flags to enable the receiver to automatically slow the sender so as not to overflow the buffers of the receiver. TCP does not make the origin address reliable. The sequence number feature of TCP resists address-spoofing. However, it does not make it impossible. Instances of attackers pretending to be trusted nodes have been reported to have toolkits that encapsulate the necessary work and special knowledge to implement such attacks. Like many packet-switched protocols, TCP uses path diversity. This means some of the meaning of the traffic may not be available to an eavesdropper. However, eavesdropping is still possible. For example, user identifiers and passphrases usually move in the same packet. “Password grabber” programs have been detected in the network. These programs 336

Security of Communication Protocols and Services simply store the first 256 or 512 bits of packets on the assumption that many will contain passwords. Finally, like most stateful protocols, some TCP implementations are vulnerable to denial-of-service attacks. One such attack is called SYN flooding. Requests for sessions, SYN flags, are sent to the target, but the acknowledgments are ignored. The target allocates memory to these requests and is overwhelmed. Telnet The Telnet protocol describes how commands and data are passed from one machine on the network to another over a TCP/IP connection. It is described in RFC 855. It is used to make a terminal or printer on one machine and an operating system or application on another appear to be local to each other. The user invokes the Telnet client by entering its name or clicking its icon on his local system and giving the name or address and port number of the system or application that he wishes to use. The Telnet client must listen to the keyboard and send the characters entered by the user across the TCP connection to the server. It listens to the TCP connection and displays the traffic on the user’s terminal screen. The client and server use an escape sequence to distinguish between user data and their communication with each other. The Telnet service is a frequent target of attack. By default, the Telnet service listens for log-in requests on port 23. Connecting this port to the public network can make the system and the network vulnerable to attack. When connected to the public Net, this port should expect strong authentication or accept only encrypted traffic. File Transfer Protocol (FTP) FTP is the protocol used on the Internet for transferring files between two systems. It divides a file into IP packets for sending it across the Internet. The object of the transfer is a file. The protocol provides automatic checking and retransmission to provide for bit-for-bit integrity. (See section titled Services below.) Serial Line Internet Protocol (SLIP) SLIP is a protocol for sending IP packets over a serial line connection. It is described in RFC 1055. SLIP is often used to extend the path from an IPaddressable device, like a router at an ISP, across a serial connection (e.g., a dial connection) to a non-IP device (e.g., a serial port on a PC). It is a mechanism for attaching non-IP devices to an IP network. 337

SECURITY SLIP encapsulates the IP packet and bits in the code used on the serial line. In the process, the packet may gain some redundancy and error correction. However, the protocol itself does not provide any error detection or correction. This means that errors may not be detected until the traffic gets to a higher layer. Because SLIP is usually used over relatively slow (56Kbps) lines, this may make error correction at that layer expensive. On the other hand, the signaling over modern modems is fairly robust. Similarly, SLIP traffic may gain some compression from devices (e.g., modems) in the path, but does not provide any compression of its own. Because the serial line has only two end-points, the protocol does not contain any address information; that is, the addresses are implicit. However, this limits the connection to one application; any distinctions in the intended use of the line must be handled at a higher layer. Insofar as SLIP is used on point-to-point connections, it may be slightly less vulnerable to eavesdropping than a shared-media connection like Ethernet. However, because it is closer to the end-point, the data may be more meaningful. This observation also applies to PPP below. Point-to-Point Protocol (PPP) PPP is used for applications and environments similar to those for SLIP, but is more sophisticated. It is described in RFC 1661, July 1994. It is the Internet standard for transmission of IP packets over serial lines. It is more robust than SLIP and provides error-detection features. It supports both asynchronous and synchronous lines and is intended for simple links that deliver packets between two peers. It enables the transmission of multiple network-layer protocols (e.g., ip, ipx, spx) simultaneously over a single link. For example, a PC might run a browser, a Notes client, and an e-mail client over a single link to the network. To facilitate all this, PPP has a Link Control Protocol (LCP) to negotiate encapsulation formats, format options, and limits on packet format. Optionally, a PPP node can require that its partner authenticate itself using CHAP or PAP. This authentication takes place after the link is set up and before any traffic can flow. (See CHAP and PAP below.) Hyper-Text Transfer Protocol (HTTP) HTTP is used to move data objects (called pages) between client applications (called browsers) running on one machine, and server applications, usually on another. HTTP is the protocol used on and that defines the World Wide Web. The pages moved by HTTP are compound data objects composed of other data and objects. Pages are specified in a language called HyperText Markup Language (HTML). HTML specifies the 338

Security of Communication Protocols and Services appearance of the page and provides for pages to be associated with one another by cross-references called hyperlinks. The fundamental assumption of HTTP is that the pages are public and that no data-hiding or address reliability is necessary. However, because many electronic commerce applications are done on the World Wide Web, other protocols, described below, have been defined and implemented. SECURITY PROTOCOLS Most of the traffic that moves in the primitive TCP/IP protocols is public, (i.e., none of the value of the data derives from its confidentiality). Therefore, the fact that the protocols do not provide any data-hiding does not hurt anything. The protocols do not add any security, but the data does not need it. However, there is some traffic that is sensitive to disclosure and does require more security than the primitive protocols provide. The absolute amount of this traffic is clearly growing, and its proportion may be growing also. In most cases, the necessary hiding of this data is done in alternate or higher-level protocols. A number of these secure protocols have been defined and are rapidly being implemented and deployed. This section describes some of those protocols. Secure Socket Layer (SSL) Arguably, the most widely used secure protocol is SSL. It is intended for use in client/server applications in general. More specifically, it is widely used between browsers and Web servers on the WWW. It uses a hybrid of symmetric and asymmetric key cryptography, in which a symmetric algorithm is used to hide the traffic and an asymmetric one, RSA, is used to negotiate the symmetric keys. SSL is a session-oriented protocol; that is, it is used to establish a secure connection between the client and the server that lasts for the life of the session or until terminated by the application. SSL comes in two flavors and a number of variations. At the moment, the most widely used of the two flavors is one-way SSL. In this implementation, the server side has a private key, a corresponding public key, and a certificate for that key-pair. The server offers its public key to the client. After reconciling the certificate to satisfy itself as to the identity of the server, the client uses the public key to securely negotiate a session key with the server. Once the session key is in use, both the client and the server can be confident that only the other can see the traffic. The client side has a public key for the key-pair that was used to sign the certificate and can use this key to verify the bind between the key-pair and 339

SECURITY the identity of the server. Thus, the one-way protocol provides for the authentication of the server to the client — but not the other way around. If the server cares about the identity of the client, it must use the secure session to collect evidence about the identity of the client. This evidence is normally in the form of a user identifier and a passphrase or similar, previously shared, secret. The other flavor of SSL is two-way SSL. In this implementation, both the client and the server know the public key of the other and have a certificate for this key. In most instances, the client’s certificate is issued by the server, while the server’s certificate was issued by a mutually trusted third party. Secure-HTTP (SHTTP) SHTTP is a secure version of HTTP designed to move individual pages securely on the World Wide Web. It is page oriented as contrasted to SSL, which is connection or session oriented. Most browsers (thin clients) that implement SSL also implement SHTTP, may share key-management code, and may be used in ways that are not readily distinguishable to the end user. In other applications, SHTTP gets the nod where very high performance is required and where there is limited need to save state between the client and the server. Secure File Transfer Protocol (SFTP) Most of the applications of the primitive File Transfer Protocol are used to transfer public files in private networks. Much of it is characterized as “anonymous,” that is, one end of the connection may not even recognize the other. However, as the net spreads, FTP is increasingly used to move private data in public networks. SFTP adds encryption to the FTP protocol to add data-hiding to the integrity checking provided in the base protocol. Secure Electronic Transaction (SET) SET is a special protocol developed by the credit card companies and vendors and intended for use in multi-party financial transactions like credit card transactions across the Internet. It provides not only for hiding credit card numbers as they cross the network, but also for hiding them from some of the parties to the transaction and for protecting against replay. One of the limitations of SSL when used for credit card numbers is that the merchant must become party to the entire credit card number and must make a record of it to use in the case of later disputes. This creates a vulnerability to the disclosure and reuse of the credit card number. SET 340

Security of Communication Protocols and Services uses public-key cryptography to guarantee the merchant payment without that merchant having to know or protect the credit card number. Point-to-Point Tunneling3 Protocol (PPTP) PPTP is a protocol (from the PPTP Forum) for hiding the information in IP packets, including the addresses. It is used to connect (portable computer) clients across the dial-switched point-to-point network to the Internet and then to a (MS) gateway server to a private (enterprise) network or to (MS) servers on such a network. As its name implies, it is a point-to-point protocol. It is useful for implementing end-to-end secure virtual networks (SVNs), but less so for implementing any-gateway-to-any-gateway virtual private networks (VPNs). PPTP includes the ability to: • • • • • •

query the status of Comm Servers provide in-band management allocate channels and place outgoing calls notify server on incoming calls transmit and receive user data with flow control in both directions notify server on disconnected calls

One major advantage of PPTP is that it is included in MS 32-bit operating systems. (At this writing, the client-side software is included on 32-bit MS Windows operating systems Dial Up Networking [rel. 1.2 and 1.3]. The server-side software is included in the NT Server operating system. See L2TP below.) A limitation of PPTP, when compared to secure-IP or SSL, is that it does not provide authentication of the end-points. That is, the nodes know that other nodes cannot see the data passing between, but must use other mechanisms to authenticate addresses or user identities. Layer 2 Forwarding (L2F) L2F is another mechanism for hiding information on the Internet. The encryption is provided from the point where the dial-switched, point-topoint network connects the Internet service provider (ISP) to the gateway on the private network. The advantage is that no additional software is required on the client computer; the disadvantage is that the data is protected only on the Internet and not on the dial-switched network. L2F is a router-to-router protocol used to protect data from acquisition by an ISP across the public digital packet-switched network (Internet) to receipt by a private network. It is used by the ISP to provide data-hiding 3. Tunneling is a form of encapsulation in which the encrypted package, the passenger, is encapsulated inside a datagram of the carrier protocol.

341

SECURITY servers to its clients. Because the protocol is implemented in the routers (Cisco), its details and management are hidden from the end users. Layer 2 Tunneling Protocol (L2TP) L2TP is a proposal by MS and Cisco to provide a client-to-gateway datahiding facility that can be operated by the ISP. It responds to the limitations of PPTP (must be operated by the owner of the gateway) and L2F (does not protect data on the dial-switched point-to-point net). Such a solution could protect the data on both parts of the public network, but as a service provided by the ISP rather than by the operator of the private network. Secure Internet Protocol (Secure-IP or IPSec) IPSec is a set of protocols to provide for end-to-end encryption of the IP packets. It is being developed by the Internet Engineering Task Force (IETF). It is to be used to bind end-points to one another and to implement VPNs and SVNs. Internet Security Association Key Management Protocol (ISAKMP) ISAKMP is a proposal for a public-key, certificate-based, key-management protocol for use with IPSec. Because the user will have to have both a certificate and the corresponding key to establish a secure session and because the session will not be vulnerable to replay or eavesdropping, ISAKMP provides “strong authentication.” What is more, because the same mechanism can be used for encryption as for authentication, it provides economy of administration. Password Authentication Protocol (PAP) As noted above, PPP provides for the parties to identify and authenticate each other. One of the protocols for doing this is PAP (see also CHAP below). PAP works very much like traditional log-in using a shared secret. A sends a prompt or a request for authentication to B, and B responds with an identifier and a shared secret. If the pair of values meets A’s expectation, then A acknowledges B. This protocol is vulnerable to a replay attack; it is also vulnerable to abuse of B’s identity by a privileged user of A. Challenge Handshake Authentication Protocol (CHAP) CHAP is a standard challenge–response peer-to-peer authentication mechanism. System A chooses a random number and passes it to B. B encrypts this challenge under a secret shared with A and returns it to A. A also computes the value of the challenge encrypted under the shared 342

Security of Communication Protocols and Services secret and compares this value to the value returned by B. If this response meets A’s expectation, then A acknowledges B. Many implementations of PPP/CHAP provide that the remote party be periodically re-authenticated by sending a new challenge. This resists any attempt at “session stealing.” SERVICES File Transfer FTP is the name of a protocol, but it is also the name of a service that uses the protocol to deliver files. The service is symmetric in that either the server or the client can initiate a transfer in either direction, either can get a file or send a file, either can do a get or a put. The client may itself be a server. The server may or may not recognize its user, may or may not restrict access to the available files. Where the server does restrict access to the available files, it usually does that through the use of the control facilities of the underlying file system. If the file server is built upon the UNIX operating system and file system or the Windows operating systems, then it will use the rules-based file access controls of the file system. If the server is built upon the NT operating system, then it will use the object-oriented controls of the NT file system. If the file service is built on MVS — and yes that does happen — then it is the optional access control facility of MVS that will be used. Secure Shell (SSH 2) Secure Shell is a UNIX-to-UNIX client/server program that uses strong cryptography for protecting all transmitted data, including passwords, binary files, and administrative commands between systems on a network. One can think of it as a client/server command processor or shell. While it is used primarily for system management, it should not be limited to this application. It implements Secure IP and ISAKMP at the application layer, as contrasted to the network layer, to provide a secure network computing environment. It provides node identification and authentication, node-to-node encryption, and secure command and file transfer. It compensates for most of the protocol limitations noted above. It is now preferred to and used in place of more limited or application-specific protocols or implementations such as SFTP. CONCLUSIONS Courtney’s first law says that nothing useful can be said about the security of a mechanism except in the context of an application and an environment. Of course, the converse of that law says that, in such a context, one can say quite a great deal. 343

SECURITY The Internet is an open, not to say hostile, environment in which most everything is permitted. It is defined almost exclusively by its addresses and addressing schema and by the protocols that are honored in it. Little else is reliable. Nonetheless, most sensitive applications can be done there as long as one understands the properties and limitations of those protocols and carefully chooses among them. There are a large number of protocols defined and implemented on the Internet. No small number of them are fully adequate for all applications. On the other hand, the loss in performance, flexibility, generality, and function in order to use those that are secure for the intended application and environment are small. What is more, as the cost of performance falls, the differences become even less significant. The IS manager must (1) understand the needs of the applications; (2) know the tools, protocols, and what is possible in terms of security; and then (3) carefully choose and apply those protocols and implementations.

344

Chapter 28

Firewall Management and Internet Attacks Jeffery J. Lowder

NETWORK CONNECTIVITY CAN BE BOTH A BLESSING AND A CURSE. On the one hand, network connectivity can enable users to share files, exchange e-mail, and pool physical resources. Yet network connectivity can also be a risky endeavor if the connectivity grants access to would-be intruders. The Internet is a perfect case in point. Designed for a trusted environment, many contemporary exploits are based on vulnerabilities inherent to the protocol itself. According to a recent dissertation by John Howard on Internet unauthorized access incidents reported to the Computer Emergency Response Team (CERT), there were 4567 incidents between 1989 and 1996, with the number of incidents increasing each year at a rate of 41 to 62 percent. In light of this trend, many organizations are implementing firewalls to protect their internal network from the untrusted Internet. LAYING THE GROUNDWORK FOR A FIREWALL Obtaining management support for a firewall prior to implementation can be very useful after the firewall is implemented. When a firewall is implemented on a network for the first time, it will almost surely be the source of many complaints. For example: • Organizations that have never before had firewalls almost always do not have the kind of documentation necessary to support user requirements. • If the firewall hides information about the internal network from the outside network, this will break any network transactions in which the remote system uses an access control list and the address of the firewall is not included in that list. • Certain types of message traffic useful in network troubleshooting (e.g., PING, TRACEROUTE) may no longer work. All of these problems can be solved, but the point is that coordination with senior management prior to installation can make life much easier for firewall administrators. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

345

SECURITY Benefits of Having a Firewall So how does one obtain management support for implementation of a firewall? The security practitioner can point out the protection that a firewall provides: protection of the organization’s network from intruders, protection of external networks from intruders within the organization, and protection from “due care” lawsuits. The security practitioner can also list the positive benefits a firewall can provide: • Increased ability to enforce network standards and policies. Without a firewall or similar device, it is easy for users to implement systems that the Information Services (IS) department does not know about, that are in violation of organizational standards or policies, or both. In contrast, organizations find it very easy to enforce both standards and policies with a firewall that blocks all network connections by default. Indeed, it is not uncommon for organizations to discover undocumented systems when they implement such a firewall for the first time. • Centralized internetwork audit capability. Because all or most traffic between the two networks must pass through the firewall (see below), the firewall is uniquely situated to provide audit trails of all connections between the two networks. These audit trails can be extremely useful for investigating suspicious network activity, troubleshooting connectivity problems, measuring network traffic flows, and even investigating employee fraud, waste, and abuse. Limitations of a Firewall Even with all of these benefits, firewalls still have their limitations. It is important that the security practitioner understand these limitations because if these limitations allow risks that are unacceptable to management, it is up to the security practitioner to present additional safeguards to minimize these risks. The security practitioner must not allow management to develop a false sense of security simply because a firewall has been installed. • Firewalls provide no data integrity. It is simply not feasible to check all incoming traffic for viruses. There are too many file formats and often files are sent in compressed form. Any attempt to scan incoming files for viruses would severely degrade performance. Firewalls have plenty of processing requirements without taking on the additional responsibility of virus detection and eradication. • Firewalls do not protect traffic that is not sent through them. Firewalls cannot protect against unsecured, dial-up modems attached to systems inside the firewall; internal attacks; social engineering attacks; or data that is routed around them. It is not uncommon for an organization to 346

Firewall Management and Internet Attacks install a firewall, then pass data from a legacy system around the firewall because its firewall did not support the existing system. • Firewalls may not protect anything if they have been compromised. Although this statement should be obvious, many security practitioners fail to educate senior management on its implications. All too often, senior management approves — either directly or through silence — a security posture that positively lacks an internal security policy. Security practitioners cannot allow perimeter security via firewalls to become a substitute for internal security. • Firewalls cannot authenticate datagrams at the transport or network layers. A major security problem with the TCP/IP is that any machine can forge a packet claiming to be from another machine. This means that the firewall has literally no control over how the packet was created. Any authentication must be supported in one of the higher layers. • Firewalls provide limited confidentiality. Many firewalls have the ability to encrypt connections between two firewalls (using a so-called virtual private network, or VPN), but they typically require that the firewall be manufactured by the same vendor. A firewall is no replacement for good host security practices and procedures. Individual system administrators still have the primary responsibility for preventing security incidents. FIREWALLS AND THE LOCAL SECURITY POLICY Cheswick and Bellovin (1994) define a firewall as a system with the following set of characteristics: • All traffic between the two networks must pass through the firewall. • Only traffic that is authorized by the local security policy will be allowed to pass. • The firewall itself is immune to penetration. Like any security tool, a firewall merely provides the capability to increase the security of the path between two networks. It is the responsibility of the firewall administrator to take advantage of this capability; and no firewall can guarantee absolute protection from outside attacks. The risk analysis should define the level of protection that can be expected from the firewall; the local security policy should provide general guidelines on how this protection will be achieved; and both the assessment and revised policy should be accepted by top management prior to firewall implementation. Despite the fact that, according to Atkins et al.,1 all traffic between the two networks must pass through the firewall, in practice this is not always technically feasible or convenient. Network administrators supporting legacy or proprietary systems may find that getting them to communicate 347

SECURITY through the firewall may not be as easy as firewall vendors claim, if even possible. And even if there are no technical obstacles to routing all traffic through the firewall, users may still complain that the firewall is inconvenient or slows down their systems. Thus, the local security policy should specify the process by which requests for exceptions1 will be considered. As Bellovin2 states, the local security policy defines what the firewall is supposed to enforce. If a firewall is going to allow only authorized traffic between two networks, then the firewall has to know what traffic is authorized. The local security policy should define “authorized” traffic, and it should do so at a somewhat technical level. The policy should also state a default rule for evaluating requests: either all traffic is denied except that which is specifically authorized, or all traffic is allowed except that which is specifically denied. Network devices that protect other network devices should themselves be protected against intruders. (If the protection device itself is not secure, intruders could compromise the device and then compromise the system[s] that the device is supposed to protect.) FIREWALL EVALUATION CRITERIA Choosing the right firewall for an organization can be a daunting task, given the complexity of the problem and the wide variety of products from which to choose. Yet the following criteria should help the security practitioner narrow the list of candidates considerably. • Performance. Firewalls always impact the performance of the connection between the local and remote networks. Adding a firewall creates an additional hop for network packets to travel through; if the firewall must authenticate connections, that creates an additional delay. The firewall machine should be powerful enough to make these delays negligible. • Requirements support. A firewall should support all of the applications that an organization wants to use across the two networks. Virtually all firewalls support fundamental protocols like SMTP, Telnet, FTP, and HTTP; strong firewalls should include some form of circuit proxy or generic packet relay. The security practitioner should decide what other applications are required (e.g., Real Audio, VDOLive, SHTTP, etc.) and evaluate firewall products accordingly. • Access control. Even the simplest firewalls support access control based on IP addresses; strong firewalls will support user-based access control and authentication. Large organizations should pay special attention to whether a given firewall product supports a large number of user profiles and ensure that the firewall can accommodate increased user traffic. 348

Firewall Management and Internet Attacks • Authentication. The firewall must support the authentication requirements of the local security policy. If implementation of the local security policy will entail authenticating large numbers of users, the firewall should provide convenient yet secure enterprisewide management of the user accounts. Some firewalls only allow the administrator to manage user accounts from a single console; this solution is not good enough for organizations with thousands of users who each need their own authentication account. Moreover, there are logistical issues that need to be thought out. For example, suppose the local security policy requires authentication of all inbound telnet connections. How will geographically separated users obtain the proper authentication credentials (e.g., passwords, hard tokens, etc.)? • Physical security. The local security policy should stipulate the location of the firewall, and the hardware should be physically secured to prevent unauthorized access. The firewall must also be able to interface with surrounding hardware at this location. • Auditing. The firewall must support the auditing requirements of the local security policy. Depending on network bandwidth and the level of event logging, firewall audit trails can become quite large. Superior firewalls will include a data reduction tool for parsing audit trails. • Logging and alarms. What logging and alarms does the security policy require? If the security policy dictates that a potential intrusion event trigger an alarm and mail message to the administrator, the system must accommodate this requirement. • Customer support. What level of customer support does the firewall vendor provide? If the organization requires 24-hour-a-day, 365-day-ayear technical support, is it available? Does the vendor provide training courses? Is self-help online assistance, such as a Web page or a mailing list, available? • Transparency. How transparent is the firewall to the users? The more transparent the firewall is to the users, the more likely they will be to support it. On the other hand, the more confusing or cumbersome the firewall, the more likely the users are to resist it. FIREWALL TECHNIQUES There are three different techniques available to firewalls to enforce the local security policy: packet filtering, application-level gateways, and circuit-level gateways. These techniques are not mutually exclusive; in practice, firewalls tend to implement multiple techniques to varying extents. This section defines these firewall techniques. Packet Filtering Packet filters allow or drop packets according to the source or destination address or port. The administrator makes a list of acceptable and 349

SECURITY Exhibit 28-1. Rule Number

Action

0 1

Allow Deny

Sample packet filter configuration.

Local Host

Local Port

Remote Host

Remote Port

WWW server *

80 *

* *

* *

unacceptable machines and services, and configures the packet filter accordingly. This makes it very easy for the administrator to filter access at the network or host level, but impossible to filter access at the user level (see Exhibit 28-1). The packet filter applies the rules in order from top to bottom. Thus, in Exhibit 28-1, rule 0 blocks all network traffic by default; rule 1 creates an exception to allow unrestricted access on port 80 to the organization’s Web server. But what if the firewall administrator wanted to allow telnet access to the Web server by the webmaster? The administrator could configure the packet filter as shown in Exhibit 28-2. The packet filter would thus allow telnet access (port 23) to the Web server from the address or addresses represented by <machine room>, but the packet filter has no concept of user authentication. Thus, unauthorized individuals originating from the <machine room> address(es) would be allowed telnet access to the WWW server, while authorized individuals originating from non-<machine room> address(es) would be denied access. In both cases, the lack of user authentication would prevent the packet filter from enforcing the local security policy. Application-Level Gateways Unlike packet filters, application-level gateways do not enforce access control lists. Instead, application-level gateways attempt to enforce connection integrity by ensuring that all data passed on a given port is in accordance with the protocol for that port. This is very useful for preventing transmissions prohibited by the protocol, but not handled properly by the remote system. Consider, for example, the Hypertext Transmission Protocol (HTTP) used by WWW servers to send and receive information, normally on port 80. Intruders have been able to compromise numerous servers by transmitting special packets outside the HTTP specification. Exhibit 28-2. Rule Number 0 1 2

350

Packet filter configuration to allow Telnet access from <machine room> to <www-server>.

Action Allow Allow Deny

Local Host

Local Port

Remote Host

Remote Port

WWW server WWW server *

80 23 *

* <machine room> *

* * *

Firewall Management and Internet Attacks Pure packet filters are ineffective against such attacks because they can only restrict access to a port based on source and destination address; but an application gateway could actually prevent such an attack by enforcing the protocol specification for all traffic on the related port. The application gateway relays connections in a manner similar to that of the circuit-level gateway (see below), but it provides the additional service of checking individual packets for the particular application in use. It also has the additional ability to log all inbound and outbound connections. Circuit-Level Gateways A circuit-level gateway creates a virtual circuit between the local and remote networks by relaying connections. The originator opens a connection on a port to the gateway, and the gateway in turn opens a connection on that same port to the remote machine. The gateway machine relays data back and forth until the connection is terminated. Because circuit-level gateways relay packets without inspecting them, they normally provide only minimal audit capabilities and no application-specific controls. Moreover, circuit-level gateways require new or modified client software that does not attempt to establish connections with the remote site directly; the client software must allow the circuit relay to do its job. Still, circuit relays are transparent to the user. They are well-suited for outbound connections in which authentication is important but integrity is not. See Exhibit 28-3 for a comparison of these firewall techniques. DEVELOPING A FIREWALL POLICY AND STANDARDS Reasons for Having Firewall Policy and Standards There are a number of reasons for writing formal firewall policies and standards, including: • Properly written firewall policies and standards will address important issues that may not be covered by other policies. Having a generic corporate policy on information systems security is not good enough. There are a number of specific issues that apply to firewalls but would not be addressed, or addressed in adequate detail, by generic security policies. • A firewall policy can clarify how the organization’s security objectives apply to the firewall. For example, a generic organizational policy on information protection might state that, “Access to information is granted on a need-to-know basis.” A firewall policy would interpret this objective by stating that, “All traffic is denied except that which is explicitly authorized.” 351

SECURITY Exhibit 28-3. Firewall Technique

Advantages and disadvantages of firewall techniques. Advantages

Disadvantages

Packet filtering

Completely transparent Easy to filter access at the host or network level Inexpensive: can use existing routers to implement

Application-level gateways

Application-level security Strong user access control Strong logging and auditing support Ability to conceal internal network Transparent to user Excellent for relaying outbound connections

Reveals internal network topology Does not provide enough granularity for most security policies Difficult to configure Does not support certain traffic Susceptible to address spoofing Limited or no logging, alarms No user authentication Requires specialized proxy for each service Slower to implement new services Inconvenient to end users No support for client software that does not support redirection Inbound connections risky Must provide new client programs

Circuit-level gateways

• An approved set of firewall standards makes configuration decisions much more objective. A firewall, especially one with a restrictive configuration, can become a hot political topic if the firewall administrator wants to block traffic that a user really wants. Specifying the decision-making process for resolving such issues in a formal set of standards will make the process much more consistent to all users. Everyone may not always get what he or she wants, but at least the issue will be decided through a process that was adopted in advance. Policy and Standards Development Process The following process is recommended as an efficient, comprehensive way to develop a firewall policy. If the steps of this process are followed in order, the security practitioner can avoid making time-wasting oversights and errors in the policy. (See also Exhibit 28-4). 1. Risk analysis. An organization should perform a risk analysis prior to developing a policy or a set of standards. The risk analysis will not only help policy-makers identify specific issues to be addressed in the document itself, but also the relative weight policy-makers should assign to those issues. 2. Identify list of topics to cover. A partial listing of topics is suggested under Policy Structure later in this chapter; security policy-makers should also identify any other relevant issues that may be relevant to the organization’s firewall implementation. 3. Assign responsibility. An organization must define the roles and responsibilities of those accountable for administering the firewall. If 352

Firewall Management and Internet Attacks

4.

5.

6.

7.

necessary, modify job descriptions to reflect the additional responsibility for implementing, maintaining, and administering the firewall, as well as establishing, maintaining, and enforcing policy and standards. Define the audience. Is the policy document intended to be read by IS personnel only? Or is the document intended to be read by the entire organization? The document’s audience will determine its scope, as well as its degree of technical and legal detail. Write the policy. Because anyone can read the document, write without regard to the reader’s position within the organization. When it is necessary to refer to other organizational entities, use functional references whenever possible (e.g., “Public Relations” instead of “Tom Smith, Public Relations”). Be sure to list a contact person for readers who may have questions about the policy. Identify mechanisms to foster compliance. A policy is ineffective if it does not encourage employees to comply with the policy. Therefore, the individual(s) responsible for developing or maintaining the policy must ensure that adequate mechanisms for enforcement exist. These enforcement mechanisms should not be confused with the clause(s) of a policy that specify the consequences for noncompliance. Rather, enforcement mechanisms should include such administrative procedures as awareness and training, obtaining employee signatures on an agreement that specifies the employee has read and understands the policy and will comply with the intent. Review. New policies should be reviewed by representatives from all major departments of the organization — not just IS personnel. A special effort should be made to resolve any disagreements at this stage: the more low- and mid-level support that exists for a policy, the easier it will be to implement that policy.

After the policy has been coordinated with (and hopefully endorsed by) department representatives, the policy should be submitted to senior management for approval. It is extremely important that the most seniorlevel manager possible sign the policy. This will give the IS security staff the authority it needs to enforce the policy. Exhibit 28-4. Policy development process. 1. 2. 3. 4. 5. 6. 7.

Risk analysis Identify list of topics to cover Assign responsibility for policy Define the audience Write the policy Identify mechanisms to foster compliance Review

353

SECURITY Once the policy is adopted, it should be reviewed on at least an annual basis. A review may have one of three results: no change, revisions to the policy, or abandoning the policy. Policy Structure A policy is normally understood as a high-level document that outlines management’s general instructions on how things are to be run. Therefore, an organizational firewall policy should outline that management expects other departments to support the firewall, the importance of the firewall to the organization, etc. The structure of a firewall policy should look as follows: • Background. How does the importance of the firewall relate to overall organizational objectives (e.g., the firewall secures information assets against the threat of unauthorized external intrusion)? • Scope. To whom and what does this policy apply? • Definitions. What is a firewall? What role does it play within the enterprise? • Responsibilities. What resources and respective responsibilities need to be assigned to support the firewall? If the default configuration of the firewall will be to block everything that is not specifically allowed, who is responsible for requesting exceptions? Who is authorized to approve these requests? On what basis will those decisions be made? • Enforcement. What are the consequences for failing to meet the administrative responsibilities? How is noncompliance addressed? • Frequency of review. How often will this policy be reviewed? With which functions in the organization? • Policy coordinator. Who is the point of contact for this policy? • Date of last revision. When was this policy last revised? Firewall Standards Firewall standards can be defined minimally as a set of configuration options for a firewall. (Although firewall standards can and should address more than mere configuration issues, all firewall standards cover at least this much.) Exhibit 28-5 presents a sample outline for firewall standards. Because all firewalls come with default configurations, all firewalls have default standards. The job of the security practitioner is to draft a comprehensive set of standards governing all aspects of firewall implementation, usage, and maintenance, including but not limited to: • • • • • 354

protection of logs against unauthorized modification frequency of log review how long logs will be retained when the logs will be backed up to whom the alarms will be sent

Firewall Management and Internet Attacks Exhibit 28-5.

Sample outline of firewall standards.

I. II. III.

Definition of terms Responsibilities of the firewall administrator Statement of firewall limitations A. Inability to enforce data integrity B. Inability to prevent internal attacks IV. Firewall configuration A. Default policy (allow or deny) on network connections B. Physical location of firewall C. Logical location of firewall in relation to other network nodes D. Firewall system access policy 1. Authorized individuals 2. Authentication methods 3. Policy on remote configuration E. Supported services 1. Inbound 2. Outbound F. Blocked services 1. Inbound 2. Outbound G. Firewall configuration change management policy V. Firewall audit trail policy A. Level of granularity (e.g., we will have one entry for each FTP or HTTP download) B. Frequency of review (e.g., we will check the logs once a day) C. Access control (e.g., access to firewall audit trails will be limited to the following individuals) VI. Firewall intrusion detection policy A. Alarms 1. Alarm thresholds 2. Alarm notifications (e.g., e-mail, pager, etc.) B. Notification procedures 1. Top management 2. Public relations 3. System administrators 4. Incident response teams 5. Law enforcement 6. Other sites C. Response priorities (e.g., human safety, containment, public relations) D. Documentation procedures VII. Backups A. Frequency of incremental backups B. Frequency of system backups C. Archive of backups (e.g., we will keep backups for one year) D. Off-site backup requirements VIII. Firewall outage policy A. Planned outages B. Unplanned outages 1. Reporting procedures IX. Firewall standards review policy (e.g., this policy will be reviewed every six months)

355

SECURITY Exhibit 28-6. Sample warning banner. Per AFI 33-219 requirement: Welcome to USAFAnet United States Air Force Academy This is an official Department of Defense (DoD) computer system for authorized use only. All data contained on DoD computer systems is owned by DoD and may be monitored, intercepted, recorded, read, copied, or captured in any manner and disclosed in any manner by authorized personnel. THERE IS NO RIGHT TO PRIVACY ON THIS SYSTEM. Authorized personnel may give any potential evidence of crime found on DoD computer systems to law enforcement officials. USE OF THIS SYSTEM BY ANY USER, AUTHORIZED OR UNAUTHORIZED, CONSTITUTES EXPRESS CONSENT TO THIS MONITORING, INTERCEPTION, RECORDING, READING, COPYING, OR CAPTURING, AND DISSEMINATION BY AUTHORIZED PERSONNEL. Do not discuss, enter, transfer, process, or transmit classified/sensitive national security information of greater sensitivity than this system is authorized. USAFAnet is not accredited to process classified information. Unauthorized use could result in criminal prosecution. If you do not consent to these conditions, do not log in!

Legal Issues Concerning Firewalls If firewall audit trails need to be capable of being presented as evidence in a court of law, it is worthwhile to provide a “warning banner” to warn users about what sort of privacy they can expect. Many firewalls can be configured to display a warning banner on telnet and FTP sessions. Exhibit 28-6 shows an example of such a warning. FIREWALL CONTINGENCY PLANNING Firewall Outage What would be the impact on an organization if the firewall was unavailable? If the organization has routed all of its Internet traffic through a firewall (as it should), then a catastrophic hardware failure of the firewall machine would result in a lack of Internet connectivity until the firewall machine is repaired or replaced. How long can the organization tolerate an outage? If the outage is a catastrophic hardware failure, does one know how to repair or replace the components? How long would it take to repair or replace the components? If the organization has a firewall, the odds are that a firewall outage would have a significant impact on that organization. (If the connection between the two networks was not important to the organization, why would that organization have the connection and protect it with a firewall?) Therefore, the security practitioner must also develop contingency plans for responding to a firewall outage. These contingency plans must address three types of failures: hardware, software, and evolutionary (failure to keep pace with increasing usage requirements). 356

Firewall Management and Internet Attacks In the case of a hardware failure, the security practitioner has three options: repair, replacement, or removal. Firewall removal is a drastic measure that is not encouraged, it drastically reduces security while disrupting any user services that were specially configured around the firewall (e.g., domain name service, proxies, etc.). Smaller organizations may choose to repair their hardware because it is cheaper, yet this may not always be an option and may not be quick enough to satisfy user requirements. Conversely, access can be restored quickly by swapping in a “hot spare,” but the cost of purchasing and maintaining such redundancy can be prohibitive to smaller organizations. Significant Attacks, Probes, and Vulnerabilities To be effective, the firewall administrator must understand not only how attacks and probes work, but also must be able to recognize the appropriate alarms and audit trail entries. There are three attacks in particular with which every Internet firewall administrator should be familiar. Internet Protocol (IP) Source Address Spoofing. IP source address spoofing is not an attack itself. It is a vulnerability that can be exploited to launch attacks (e.g., session hijacking). First described by Robert T. Morris in 1985 and explained in more detail by Steven Bellovin in 1989, the first known use of IP source address spoofing was in 1994. Since then, hackers have made spoofing tools publicly available so that one need not be a TCP/IP expert in order to exploit this vulnerability.

IP source address spoofing is used to defeat address-based authentication. Many services, including rlogin and rsh, rely on IP addresses for authentication. Yet, as this vulnerability illustrates, this form of authentication is extremely weak and should only be used in trusted environments. (IP addresses provide identification, not authentication.) By its very nature, IP allows anyone to send packets claiming to be from any IP address. Of course, when an attacker sends forged packets to a target machine, the target machine will send its replies to the legitimate client, not the attacker. In other words, the attacker can send commands but will not see any output. As described below, in some cases, this is enough to cause serious damage. Although there is no way to totally eliminate IP source address spoofing, there are ways to reduce such activity. For example, a packet filter can be configured to drop all outbound packets that do not have an “inside” source address. Likewise, a firewall can block all inbound packets that have an internal address as the source address. However, such a solution will only work at the network and subnet levels. There is no way to prevent IP source address spoofing within a subnet. 357

SECURITY TCP Hijacking. TCP hijacking is used to defeat authenticated connections. It is only an attack option if the attacker has access to the packet flow. In a TCP hijacking attack, the attacker (1) is located logically between the client and the server, (2) sends a “killer packet” to the client, terminating the client’s connection to the server, and (3) then continues the connection. Denial-of-Service. A strength of public networks like the Internet lies in the fact that anyone can create a public service (e.g., a Web server or anonymous File Transfer Protocol [FTP] server) and allow literally anyone else, anonymously, to access that service. But this unrestricted availability can also be exploited in a denial-of-service attack. A denial-of-service attack exploits this unrestricted availability by overwhelming the service with requests. Although it is relatively easy to block a denial-of-service attack if the attack is generated by a single address, it is much more difficult — if not impossible — to stop a denial-of-service attack originating from spoofed, random source IP addresses.

There are two forms of denial-of-service attacks that are worth mentioning: TCP SYN Attack and ICMP Echo Flood. 1. TCP SYN Attack. The attacker floods a machine with TCP “half-open” connections, preventing the machine from providing TCP-based services while under attack and for some time after the attack stops. What makes this attack so significant is that it exploits an inherent characteristic of TCP; there is not yet a complete defense to this attack.

Under TCP (used by Simple Mail Transfer Protocol [SMTP], Telnet, HTTP, FTP, Gopher, etc.), whenever a client attempts to establish a connection to a server, there is a standard “handshake” or sequence of messages they exchange before data can be exchanged between the client and the server. In a normal connection, this handshake looks similar to the example displayed in Exhibit 28-7. The potential for attack arises at the point where the server has sent an acknowledgment (SYN-ACK) back to the client but has not yet received the ACK message. This is what is known as a half-open connection. The server maintains, in a memory, a list of all half-open connections. Unfortunately, servers allocate a finite amount of memory for storing this list, and an Exhibit 28-7. Normal TCP Handshake. Client

Server

SYN - - - - - - - - - - - - - - - - -> Server <- - - - - - - - - - - - - - - - - - - - - - - SYN-ACK ACK - - - - - - - - - - - - - - - - -> Client and server may now exchange data

358

Firewall Management and Internet Attacks attacker can cause an overflow by deliberately creating too many partially open connections. The SYN flooding is easily accomplished with IP source address spoofing. In this scenario, the attacker sends SYN messages to the target (victim) server masquerading a client system that is unable to respond to the SYNACK messages. Therefore, the final ACK message is never sent to the target server. Whether or not the SYN attack is used in conjunction with IP source address spoofing, the effect on the target is the same. The target system’s list of half-open connections will eventually fill; then the system will be unable to accept any new TCP connections until the table is emptied. In some cases, the target may also run out of memory or crash. Normally, half-open connections time-out after a certain amount of time; however, an attacker can generate new half-open connections faster than the target system’s timeout. 2. Internet Control Message Protocol (ICMP) Echo (PING) Flood. The PING flood attack is where the attacker sends large amounts of ICMP ping requests from an intermediary or “bounce” site to a victim, which can cause network congestion or outages. The attack is also known as the “smurf” attack because of a hacker tool called “Smurf,” which enables the hacker to launch this attack with relatively little networking knowledge.

Like the SYN attack, the PING flood attack relies on IP source address spoofing to add another level of indirection to the attack. In a SYN attack with IP source address spoofing, the spoofed source address receives all of the replies to the PING requests. While this does not cause an overflow on the victim machine, the network path from the bounce site to the victim becomes congested and potentially unusable. The bounce site may suffer for the same reason. There are automated tools that allow attackers to use multiple bounce sites simultaneously. Attackers can also use tools to look for network routers that do not filter broadcast traffic and networks where multiple hosts respond. Solutions include: • disabling IP-directed broadcasts at the router • configuring the operating system to prevent the machine from responding to ICMP packets sent to IP broadcast addresses • preventing IP source address spoofing by dropping packets that contain a source address for a different network 359

SECURITY CONCLUSION A firewall can only reduce the risk of a breach of security; the only guaranteed way to prevent a compromise is to disconnect the network and physically turn off all machines. Moreover, a firewall should always be viewed as a supplement to host security; the primary security emphasis should be on host security. Nonetheless, a firewall is an important security device that should be used whenever an organization needs to protect one network from another. The views expressed in this chapter are those of the author and do not reflect the official policy or position of the United States Air Force, Department of Defense, or the U.S. Government. Notes 1. Atkins, Derek et al., Internet Security Professional Reference, 2nd ed., New Riders, Indianapolis, IN, 1997. 2. Bellovin, Steven M., Security Problems in the TCP/IP Protocol Suite, Computer Communications Review, 19:2, April 1989, pp. 32–48. Available on the World Wide Web at ftp://ftp.research.att.com/dist/-internet_security/ipext.ps.Z

References Bernstein, Terry, Bhimani, Anish B., Schultz, Eugene and Siegel, Carol , Internet Security for Business, John Wiley & Sons, New York, 1996. Cheswick, W. R. and Bellovin, S. M., Firewalls and Internet Security: Repelling the Wily Hacker, Addison-Wesley, Reading, MA, 1994. Garfinkel, Simson and Spafford, Gene, Practical Unix & Internet Security, Sebastopol, CA, 1995. Howard, John D., An Analysis of Security Incidents on the Internet 1989–1995, Ph.D. dissertation, Carnegie Mellon University, Pittsburgh, PA, 1997. Huegen, Craig A., The Latest in Denial of Service Attacks: ‘Smurfing’, Oct. 18, 1998. Available on the World Wide Web at http://www.quadrunner.com/~chuegen/smurf.txt. Morris, Robert T., A Weakness in the 4.2BSD Unix TCP/IP Software, Bell Labs Computer Science Technical Repor t #117, Feb. 25, 1985. Available on the World Wide Web at ftp://ftp.research.att.com/-dist/internet_security/117.ps.Z. Wood, Charles Cresson, Policies from the Ground Up, Infosecurity News, March/April 1997, pp. 24-29.

360

Chapter 29

Internet-based Virtual Private Networks Nathan J. Muller

CARRIERS SUCH AS AT&T CORP., MCI COMMUNICATION CORP., AND Sprint Corp. began offering virtual private networks (VPNs) in the mid1980s as a means to recapture revenue lost to private lines that carried voice and data between far-flung corporate locations. With private networks, corporations paid a flat monthly fee for leased lines, instead of per-minute usage charges. This meant that companies could put as much traffic on the lines as they wanted — through such techniques as multiplexing and compression — without paying long-distance carriers anything extra. The long-distance carriers responded to this situation by making it more attractive for corporations to move their traffic back to the public network. Through intelligence embedded in their networks, carriers provided a variety of access arrangements, calling features, management tools, billing options, and volume discounts that made VPNs a more attractive alternative to private networks. Since the carrier would be responsible for maintaining the “network,” corporations could save even more money by cutting back on network management tools, technical staff, test equipment, and spares inventory. Although VPNs started out as voice-oriented, they could also handle low-speed data. But in early 1997, a wholly new trend emerged in which private data is routed between corporate locations, telecommuters, and mobile employees over carrier-provided Internet Protocol (IP) networks. Basically, this type of data service lets business users carve out their own IP-based wide area networks (WANs) within the public Internet and/or a carrier’s high-speed Internet backbone. APPLICATIONS Internet-based VPNs are suitable for a variety of applications, including remote access. At its most basic level, this type of VPN provides access to electronic mail, shared files, or the company intranet via an Internet connection. Instead of making a long-distance call to connect to a remote access server (RAS), or using an expensive private line, a 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

361

SECURITY remote user connects to a local Internet service provider (ISP) and then to a VPN server. The VPN server acts as a gateway between the Internet connection and the local network and handles user authentication. Once the VPN server verifies a user’s name and password, access to the LAN or intranet is granted. All data — including user names and passwords — sent between the remote user and the server travel over the public Internet in encrypted form to preserve privacy. Among the other applications of Internet-based VPNs are secure World Wide Web hosting, data warehousing, and video and voice conferencing between corporate locations. Even corporate paging services can be run over the VPN — either as the primary method of transport or as a backup to commercial satellite-based services. Such VPNs also can be used to segment groups on corporate intranets, similar to the way virtual local area networks (LANs) work. An Internet-based VPN can even be used to implement extranets between trading partners for such applications as electronic data interchange (EDI). Anything that can be done over the public Internet can be done over an IP-based VPN — only more securely and reliably. Security and reliability are especially important for supporting electronic commerce, expanding employee access to a corporate data warehouse, and making enterprise applications available to customers and strategic partners worldwide. Reliability is especially important when delay-sensitive applications must be supported, such as voice calls, videoconferencing, and SNA data. ADVANTAGES The current interest in implementing Internet-based VPNs is attributable to the considerable cost savings and functional benefits they offer to companies over traditional WANs. They also offer much greater adaptability when faced with changing application requirements. Among the well-documented benefits of Internet-based VPNs are the following: • Up-front capital costs for customer premises hardware — routers, multi-protocol frame-relay access devices, channel service units/data service units, modem pools, and access concentrators — are greatly reduced when using an Internet-based VPN versus the traditional enterprise WAN. • With transmission costs the single most expensive aspect of owning a WAN, companies are looking to replace dedicated point-to-point links and dial-up 800 number/toll connections with less expensive Internet connectivity. • The greater simplicity of Internet routing compared to dedicated links means remote sites need less support, which is the second most 362

Internet-based Virtual Private Networks

•

•

•

•

expensive aspect of WAN ownership. In dial access outsourcing applications, enterprise management costs fall because end-user support and troubleshooting are handled by the IP backbone provider. Internet-based VPNs provide a single, consolidated network infrastructure for LAN-to-LAN links, client-to-LAN dial links, and enterprise access to the Internet. Eliminating duplicate or overlapping WAN infrastructures further reduces operational costs and management overhead. Management is greatly simplified with Internet-based VPNs. Instead of monitoring and troubleshooting the entire WAN infrastructure and user population, corporate information technology managers need only monitor the performance metrics of the IP backbone provider to ensure compliance with service agreements. By leveraging the expertise of the IP backbone provider, the network operations of a company can actually become more proficient. In such areas as security and broadband WAN technology, the backbone provider may have more core competency than in-house staff, resulting in better-quality WAN services. Outsourcing one or more components of the WAN leaves IT departments more time to devote to advancing enterprise business objectives rather than to managing infrastructure.

For virtual leased-line applications, there are additional benefits of Internet-based VPNs, such as simplified network design compared to complex meshes of point-to-point links. There is no need to develop and test disaster recovery scenarios because the IP backbone provider has the responsibility for maintaining network availability. There is also easier and faster scalability when connecting new sites because this is done by the backbone provider, rather than by the IT department having to add and configure dedicated connections. For global Internet access/dial access outsourcing applications, the additional benefits of Internet-based VPNs include ubiquitous access via Internet Points of Presence compared to limited coverage for local calling areas and the absence of 800-services from international locations. There is also greater ability to scale the remote user population compared to adding remote access ports and circuits at a central corporate site. Finally, inexpensive, industry-standard client software is available for dialing remote networks. IMPLEMENTATION There are several proprietary and standard ways to implement Internetbased VPNs. Among the vendor-provided solutions are the Point-to-Point Tunneling Protocol (PPTP), the Layer 2 Forwarding (L2F) protocol, and the Layer 2 Tunneling Protocol (L2TP). These protocols are used to create tunnels, which are end-to-end connections similar to virtual circuits. Essentially, 363

SECURITY they transport Layer 3 packets such as AppleTalk, IP, and Internetwork Packet Exchange (IPX) over the Internet by encapsulating them in Layer 2 PPP (Point-to-Point Protocol) frames. Although a single standards-based approach to Virtual IP has not yet caught on, there are two possibilities emerging: the IP Security (IPsec) protocol and SOCKS, a circuit-level proxy solution. Both are open to any form of authentication and encryption. SOCKS has been ratified by the Internet Engineering Task Force (IETF), and IPsec is in the process of being ratified. Although some vendors already support IPsec, it may not see widespread use until IPv6 — the next generation of TCP/IP. Point-to Point Tunneling Protocol Microsoft Corp.’s PPTP uses a process called tunneling to ensure secure data transmission over the Internet between remote clients and corporate servers. PPTP uses MS-CHAP for authentication across Windows NT domains, giving users the same access privileges they would have if they were directly connected to the corporate network. PPTP also supports data encryption, flow control, and multiple protocols, including AppleTalk, IPX/Sequenced Packet Exchange, NetBEUI and others, allowing remote users to access the corporate network with almost any protocol at hand. Typically, a Windows NT or Windows 95 client uses a PPTP driver as its WAN driver. The client accesses a remote LAN by connecting to a PPTPenabled Windows NT RAS at the corporate site. During initial session negotiation, a 40-bit key is exchanged between the client and server. The session — including source and destination information — is secured using RSA RC4 encryption. This level of encryption also prevents the company’s own network from being able to read the destination information in the packet. This is overcome, however, by encapsulating the PPP packet within a generic routing encapsulation (GRE) packet, which includes the destination information. The large installed base of Windows NT servers and the free distribution of the PPTP client have made PPTP the most widely used VPN technology. However, Microsoft’s PPTP solution offers only one form of encryption and authentication. In addition, some routers and firewalls are not able to forward the GRE packets required by PPTP. Careful attention to compatibility issues is needed before committing to PPTP. Layer 2 Forwarding L2F and PPTP have the same objective: to enable organizations to move their remote access services to the Internet using tunnels. In many respects, L2F is very similar to PPTP. Although both support multi-protocol services, L2F is intended for IP-only backbones because it relies specifically on the User Datagram Protocol (UDP). L2F also does not support Dial-Out. 364

Internet-based Virtual Private Networks L2F relies on the corporate gateway to provide user authentication. By allowing end-to-end connectivity between remote users and their corporate gateway, all authorization can be performed as if the remote users are dialed in to the corporate location directly. This set-up frees the ISP from having to maintain a large database of individual user profiles based on many different corporations. More importantly, the virtual dial-up service becomes more secure for the corporations using it because it allows the corporations to quickly react to changes in their remote user community. For each L2F tunnel established, L2F tunnel security generates a unique random key to resist spoofing attacks within the L2F tunnel, each multiplexed session maintains a sequence number to prevent the duplication of packets. Cisco Systems, Inc., provides the flexibility of allowing users to implement compression at the client end. In addition, encryption on the tunnel can be done using IPsec. Layer 2 Tunnel Protocol Whereas Microsoft’s PPTP is a software solution, Cisco’s L2F is a hardware solution that requires the ISP and corporate site to have network access servers and routers equipped with the Cisco Internetwork Operating System software, which provides L2F functionality. Because Cisco routers account for about 80 percent of the routers used on the Internet and corporate intranets, L2F can be viewed as a de facto industry standard in the same way as Microsoft’s PPTP is viewed. The problem is that PPTP and L2F are not interoperable. The forthcoming L2TP standard is intended to rectify this situation. L2TP is a combination of PPTP and L2F, which is under consideration as an IETF standard. It seeks to allow all functions of L2F and PPTP to be compatible, thus allowing current users and implementers to continue deploying their preferred solution with an eye toward its future interoperability. L2TP uses many of the existing PPTP messages, slightly reformatted, over UDP, instead of using TCP for the control channel and GRE for the data channel. L2TP also retains the basic L2F authentication scheme and adds flow control. L2TP also improves on L2F by not requiring special hardware support. IPsec IPsec is a suite of IETF protocols that provides a high degree of security. Instead of tunneling data such as PPTP and L2F, IPsec provides packet-bypacket authentication, encryption, and integrity. Authentication positively identifies the sender. Encryption allows only the intended receiver to read the data. Integrity guarantees that no third party has tampered with the packet stream. These security functions must 365

SECURITY be applied to every IP packet because Layer-3 protocols such as IP are stateless; that is, there is no way to be sure whether or not a packet is really associated with a particular connection. Higher-layer protocols such as Transmission Control Protocol (TCP) are stateful, but connection information can be easily duplicated or “spoofed” by knowledgeable hackers. To implement these security features, IPsec packets use two headers: the Authentication Header (AH) and the Encapsulating Security Payload (ESP). The AH verifies that the data within the packet has not been tampered with, while the ESP encrypts the data so it remains private. The key limitation of IPsec is that it can only carry IP packets, whereas the other tunneling protocols support IPX and AppleTalk, among others, as well as IP. Although it specifies encryption and authentication, IPsec does not include any method of access control other than packet filtering. Although IPsec may not see widespread use until IPv6—the next generation of TCP/IP—some vendors already have products available that support it. The International Computer Security Association (ICSA) even runs an IPsec Certification Program that tests vendors’ implementations of IPsec in terms of how well they support its security functions. ICSA IPsec certification indicates that the products meet at least the minimum set of required elements to prove baseline interoperability among products of different vendors. SOCKS Another protocol used for implementing VPN is SOCKS, an IETF standard. Because SOCKS operates at Layer 5 (the session layer), it offers more functionality. For example, it has the ability to perform much finer grain access control than the lower-layer tunneling solutions, which are deployed at Layers 2 and 3. And like IPsec, but unlike the tunneling protocols, SOCKS has the ability to take advantage of a variety of different authentication and encryption mechanisms, including Secure Sockets Layer (SSL), Kerberos, Challenge Handshake Authentication Protocol (CHAP), Remote Authentication Dial-in User Service (RADIUS), and Windows NT domain authentication. Further, these methods are negotiated during the connection process. The SOCKS solution requires each user to install software that first intercepts data from the TCP/IP stack and then passes it on to the SOCKS server for authentication. Data is encrypted at both the client and server levels. Although SOCKS is more functional because it operates at Layer 5, it requires more overhead system resources during communications back and forth between networks. Protocols operating at the second and third layers provide less functionality but require less system overhead. In addition, the 366

Internet-based Virtual Private Networks lower-layer protocols can be independent of client software, which makes for easier upgrades whenever needed. SOCKS is a directional protocol, which means it operates in a single direction. Directional protocols are inherently more secure than tunneling protocols, which are bidirectional. Because SOCKS operates in a directional manner, the user can see other users and access shared data, but they cannot see back. Tunneling allows bidirectional communication, so all users can see and share data with one another. Directionality, however, is a compromise between flexibility and security. Directional communications are more secure because a user’s data cannot be shared and redistributed. Bidirectional connections are more flexible and allow better communication between remote and local users. At about $7500 for a 50-client package, SOCKS can be very expensive for many companies to implement, especially when compared to Microsoft’s PPTP, which is included free in Windows 95 and Windows NT. Although PPTP and SOCKS do not integrate, both can be run on the same system. This would give users the option of using SOCKS for higher security when running such applications as e-mail, but using PPTP when they need multi-protocol support for accessing hosts or shared applications. When connecting through PPTP, they would still have RSA RC4 encryption for security. It is becoming quite common for vendors to support multiple tunneling protocols, especially when the equipment is used to support extranets between trading partners. Bay Networks, Inc., for example, offers its Extranet Switch 1000, which supports L2TP, PPTP, IPsec, and L2F. Priced at $7000, the Extranet Switch 1000 ships with a free, unlimited user license of the client software. VENDOR OFFERINGS With appropriate protocol support from an ISP, companies can build their own Internet-based VPN from firewalls, routers, RAS, and other network devices. However, getting all this equipment working together to implement such things as authentication, access rights, and usage policies is often quite difficult. Companies wishing to build an Internet-based VPN are finding that they require products that are more integrated, flexible, and easy to set up and administer. Fortunately, vendors are addressing these needs with appropriate solutions so that even small companies with limited expertise can establish Internet-based VPNs. Assured Digital In the development of its Dynamic VPN Switching product line, Assured Digital, Inc. (ADI), for example, set out with the goal of making it quick and 367

SECURITY easy for network managers to implement and manage secure VPN solutions for any type of business application over any type of access mode. The company’s net-centric VPN solution is as easy to install and manage as a typical network hub and requires no manual configuration or on-site maintenance. To make a network manager’s job easier, the embedded routers in ADI’s Dynamic VPN Switching network devices self-configure and automatically adapt to topology changes. Within an existing secure network ad hoc communities of interest can be created on-the-fly. For example, if communications suddenly increase between two branch offices, the VPN switches automatically select the optimum path based on connection policies and routing parameters. The switches reroute traffic from the central site to a direct link that efficiently uses bandwidth, reduces network traffic, and saves money. At the heart of the automated operations of Dynamic VPN Switching is ADI’s hardware/software-based Automated Operation and Security (AOS) system, which is built into each ADI device. AOS supports IPsec, PPTP, and X.509 certificates and can accommodate future network security standards. AOS delivers policy-based authorization, secures policy distribution, maintains wire-speed encryption, and protects both data and user messages from replay. It also includes a unique cryptographic identity embedded into each device, which eliminates the complications that usually arise when trying to securely distribute encryption keys over a network or the Internet. The integration of AOS in the ADI Management System (AMS) further automates VPN management. For example, when a new ADI device is deployed, the AMS automatically initializes, authenticates, configures, and updates all the required network and security parameters to establish multiple VPN connections. The AMS also integrates with existing authentication services, such as RADIUS. VPNet Technologies VPNet Technologies, Inc. offers a variety of VPN products that provide flexible configuration alternatives for large enterprises, small businesses, and remote offices. The VSU-10 VPN Service Unit, for example, enables small businesses to use the Internet for real-time IPsec-compliant VPN connectivity at up to 8Mbps, while VPNmanager includes all the components necessary to create VPN for up to 100 users. The company also provides enterprise versions of these products, plus client software that extends IPsec-based VPN capabilities to mobile workers and telecommuters with Windows NT-based PCs. 368

Internet-based Virtual Private Networks The VSU-10 allows users to create many types of VPN configurations, either alone or with other VPNet products, depending on the structure of the enterprise and its specific needs. Small, single-site businesses can slash remote access costs by using the VSU-10 to connect their employees, partners, and suppliers over the Internet. Companies with multiple offices can use the VSU-10 to connect each of their sites into a secure VPN. In addition, home-based telecommuters can use the VSU-10 for secure, highcapacity data communications that cost a fraction of traditional, dedicated services. The VSU-10 can be deployed in any 10Base-T network. Two 10Base-T ports provide LAN connectivity and support a range of connection topologies. The unit can be installed to provide VPN services for an entire site. Services can also be restricted to a portion of the network or even to a single hub or server. In addition to supporting IPsec encryption with both data encryption standard (DES) and Triple-DES, the VSU-10 provides packet-level authentication using HMAC-MD5 and features simple key management for IP-based key management. The base unit also supports packet compression in hardware to mitigate the performance-reducing effects of IPsec packet expansion and resulting packet fragmentation. The unit can also integrate with RADIUS servers. The Java-based VPN manager brings the ease and familiarity of World Wide Web browsers to the management of VPNs. Network managers can define, configure, and manage VPNs from any location equipped with a computer hosting a Java-compatible browser. Managers can configure and check the status of VSU-10 devices, add dial-in users to a VPN, monitor the performance of private data transmissions, and troubleshoot existing configurations. SSL is used to communicate with remote VPN Service Units using either password- or certificate-based authentication. Bay Networks Bay Networks and Netscape Communications Corp. are developing a Directory-Enabled Networking (DEN) solution that will lower the cost of ownership for VPNs and extranets by linking administration of network hardware with enterprise-class directory software services. Netscape Directory Server embedded in Bay Networks’ Contivity Extranet Switches provides the flexibility, scalability, and performance that DEN requires. The Contivity Extranet Switch product family enables companies and partners to build VPNs and extranets for private communication, collaboration, and electronic commerce. The product family supports tunneling, authentication, directory, accounting, and connectivity protocols in a single, integrated hardware architecture. 369

SECURITY DEN-enabled products simplify administration by enabling changes to be made in the directory only once and have them pushed out automatically to all devices on the network. This provides network administrators with the ability to customize access to the corporate network based on each user’s unique profile. Netscape Directory Server can also coordinate the configuration of multiple Contivity Extranet Switches, rather than force network managers to separately configure each switch directly. Other Vendors Many other vendors offer Internet-based VPN solutions as well. Aventail Corp., for example, offers a secure policy-based VPN management system based on SOCKS Version 5. Essentially, Aventail allows IT managers to develop and enforce policy-based management of access to network resources on a VPN using a single application. Internet Devices, Inc. offers its Fort Knox Policy Router, which works with installed routers and delivers VPN and firewall services. Access rights, firewall filtering, and usage policies — such as limiting Web surfing for performance or to keep users away from inappropriate sites to protect the company against hostile-work-environment lawsuits — are all controlled through a single Web-based interface. Check Point Software Technologies, Ltd. offers policy-based bandwidth management and server load balancing with its firewall products. Through a partnership with Entrust Technologies, Inc., Check Point offers a public key infrastructure to help companies manage encryption keys in VPN applications. FreeGate Corp. offers software designed to let small businesses with multiple offices and remote users set up turnkey VPN. The software runs on the company’s Multiservices Internet Gateway, a turnkey server designed to give small businesses Internet access and intranet services. Among the services included are IP routing, Web server functionality, firewall, e-mail, file transfer, and domain name services. The software lets users at multiple locations — each with a FreeGate server — connect to one another as if they were on a single LAN. Remote users can dial in to a FreeGate server using PPTP included with Windows clients. The server provides management software designed for nontechnical users. Configurations for local and remote users are propagated across the network of FreeGate servers. CARRIER SERVICES For companies that prefer to completely outsource their Internet-based VPNs, there are carriers and national ISPs that will bundle equipment and service, and manage it all for a fairly reasonable price. 370

Internet-based Virtual Private Networks The major carriers offer some compelling features with their IP-based VPN offerings. To encourage customers to consider their services, carriers also are making promises about trouble response time, network uptime, and dial port availability. The overriding concern of corporate managers, however, is end-to-end latency. If the VPN cannot get the packets through, then it is of little importance if the network is available 100 percent of the time. Accordingly, latency guarantees are becoming available. UUNet Technologies, a subsidiary of WorldCom, Inc., for example, guarantees 150 ms for latency and 99.9 percent network availability. The credit is 25 percent of the customer’s daily bill if UUNet fails to meet one criteria, and 50 percent of the daily bill if it fails to meet both. MCI claims that its OC-12 optical-fiber Internet backbone averages better than 95 ms for latency cross-country roundtrip. Under MCI’s service level agreement for its internet MCI VPN, customers get a one-day credit for any ten-minute outage. A three-hour outage will result in a three-day service credit. There are no limits to the credits that can be earned over the course of a month. Users can also access a graphical traffic report on MCI’s Web page (http://traffic.mci.com/), which shows delay and packet loss performance in near-real-time. (MCI sold its Internet infrastructure to Cable & Wireless in mid-1998 to get regulatory approval for the MCI/WorldCom merger.) AT&T WorldNet’s VPN service gives network and IT managers the ability to create closed user groups for intranets and extranets, and provides dialup access to corporate LANs for remote users. Dedicated VPN service is provided on AT&T’s frame relay network, and dial-up service uses the company’s 225-node Internet backbone. The backbone can be accessed from more than 580 central offices. AT&T enhances the reliability of its network with secure nodes and POP, a self-restoring Fastar system that minimizes the impact of cable cuts, redundant router configurations, redundant ATM switching architecture, and alternate access paths for Internet-bound packets. Network reliability for all Internet connections is 99.7 percent, which is slightly less than the 99.97 percent reliability of the public network, but high enough to persuade organizations to place daily business applications on the Internet. Because AT&T owns and controls all of its IP network equipment and facilities, it can exercise absolute control over its backbone, a key factor in ensuring reliability. AT&T maintains a physically secure Network Operations Center (NOC), as well as an identically equipped facility in a remote location. There, systems and software have been tuned to enable the NOC staff to detect, isolate, and fix any network troubles in a proactive fashion. The IP backbone network is managed by both in-band and out-of-band network monitoring systems, allowing NOC technicians to monitor realtime status of all network elements at all times: in-band via the network and 371

SECURITY out-of-band via secure dial-up. Although Simple Network Management Protocol is the primary network management protocol used in monitoring the IP backbone network, customized alarm correlation and filtering software are also used to allow quick detection of network alarms, along with custom-built tools to monitor routing tables, routing protocols, and physical and logical circuits. For security, AT&T uses RADIUS servers and Novell Directory Services to validate the authenticity of users dialing into the network using CHAP. Packet filters are used to prevent source address spoofing, which blocks outsiders from entering its network and closed user groups and from accessing client Web servers. All POP, modem pools, and authentication servers are in protected buildings. AT&T does offer a service guarantee: one free day of service if the VPN goes down for more than 15 minutes. At this writing, AT&T is adding other performance guarantees, tunneling, and value-added network management services to its VPN offering. CONCLUSION Internet-based VPNs are rapidly shaping up as a viable option to public network services. This alternative appeals to companies that are unable or unwilling to invest heavily in network infrastructure. From the carriers’ perspective, router networks cost 80 percent less to build than traditional circuit-switched networks of comparable capacity. This enables them to offer substantial cost savings. The major carriers even provide servicelevel guarantees to overcome concerns about latency and other quality-ofservice issues traditionally associated with Internet technologies. In the long term, as performance, security, and manageability continue to undergo improvements, Internet-based VPNs could very well replace traditional private networks for many mainstream business applications within a decade or so.

372

Chapter 30

The Evolving World of Network Directory Services Gilbert Held

UNTIL RECENTLY, THE USE OF NETWORK DIRECTORY SERVICE WAS LIMITED to facilitating file and print service operations. As networks grew in complexity, it was realized that the role of a network directory service could be expanded to enhance user operations by providing access to other objects within a network, such as different applications, workgroups, and even other uses. Recognizing the need to expand and enhance their network directory services, Novell and Microsoft have introduced a series of products over the past few years that considerably facilitated access to network resources. Novell was first to the market, introducing its Novell Directory Service (NDS) with NetWare 4.0 several years ago. Since then, Novell has upgraded the capabilities of its NDS through a series of new versions of their directory service, while Microsoft, until recently, was literally left in the dust with an eventually obsolete directory structure based on the relationship between domains in an NT network. With the release of Windows NT 5.0, Microsoft is back in the network directory services competition. Its Active Directory is quite similar to NDS with respect to supporting a hierarchical inverted tree structure, and its new product can be expected to satisfy a large number of Windows NT accounts that were quite vocal in asking for an enhanced directory service capability. This chapter examines the evolving world of network directory services, focusing attention on Novell’s NDS and Microsoft’s Active Directory. To provide maximum benefit, one should first review the rationale for using a directory service and some of the key functions this service can be expected to perform. Because NDS predates Microsoft’s Active Directory, attention is focused first on NDS. Once this is accomplished, one can compare and contrast some of the key features of each network directory service. Thus, in addition to making readers aware of the characteristics of a network directory service and its utilization, this chapter also acquaints readers with the functionality of NDS and Active Directory, 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

373

SECURITY as well as the similarities and differences associated with these network directory services. DIRECTORY SERVICE OVERVIEW As briefly mentioned at beginning of this chapter, a network directory service provides access to various objects associated with a network. Those objects can represent file and print resources, applications, workgroups, database servers, and even other users. A network directory service is organized in a hierarchical design that appears to resemble an inverted tree. That tree has its root at the top of the structure and consists of branches that can represent objects that are located on other networks around the globe. To facilitate the management of objects, a directory service provides a mechanism to group related objects into a higher-level structure in a manner similar to leaves falling under a tree branch. In an NDS environment, a group of objects can be placed into an organizational unit in a manner similar to the creation of an organizational chart. Each object in a network directory is associated with specific information that defines its availability for utilization, access constraints, and various operational parameters. Because the network directory service can consist of tens of thousands to millions of objects, its ability to operate effectively and efficiently depends on its elements being organized in some manner that facilitates its use. This organization is accomplished by the directory service organizing each object and its associated elements into a database. To facilitate the use of a network directory service, it needs to be able to respond to the fact that different organizations have different organizational structures. Thus, both NDS and Active Directory include the ability to customize their directory service to the differing structures associated with commercial organizations, academia, and government agencies. FEATURES Exhibit 30-1 lists the key features associated with the use of a network directory service. To obtain an appreciation of the value of each feature, this chapter briefly examines each in the order they are presented in the table. Exhibit 30-1.

Key features of a network directory service.

• Single point of log-on • Single point of administration • Fault-tolerant operations • Customization capability

374

The Evolving World of Network Directory Services Single Log-on A network directory service permits users to log into the network once using a single password. This action applies to every location on the network which results in each user, regardless of physical location, having a consistent network view of available resources. Once access to the network is gained, access requests to each object are checked against a database of permissions. To ensure that users requesting access to an object are who they claim to be, an authentication scheme is used to verify the identity of each network user. Through the ability to log into a network once to gain access to all authorized resources, employee productivity can be considerably enhanced. In addition, the hierarchical structure of a network directory service in which elements of objects can be located along an inverted tree structure reduces the effect of queries and operations on other network traffic. For example, a user might be able to drill down to locate a network resource by browsing elements in the hierarchical database structure used by a network directory service without affecting traffic flowing between another user and a network object. Single Point of Administration An enterprise network manager or administrator will greatly appreciate the fact that a directory-enabled network provides a single point of administration for the entire enterprise. In doing so, the use of a network directory service eliminates the need for redundant administration-related operations. This in turn reduces the total cost of managing and maintaining a comprehensive network that, for some enterprises, can span the globe. Fault-Tolerant Operations Recognizing the fact that the support of a single-point log-on and a single point of administration can be risky if such functions are performed by devices devoted to each function, a network directory service includes a degree of redundancy. To provide redundancy, the database that contains information on each object is distributed and replicated across the network. This provides a fault-tolerant operational capability. Customization Capability The heart of a network directory service is the directory tree. The structure of that tree, as well as its ability to define its use to include specifying objects that can be defined and attributes that can be associated with different objects, is governed by the directory schema. That schema defines a set of rules that govern the set-up and modification of the structure of the tree and its elements. 375

SECURITY Depending on the capability of the schema, one more than likely can move objects to different locations on the tree to optimize network performance, define different object attributes as user requirements change, and even add functionality to the network by adding such objects as access servers and fax servers to the directory tree. Because of the ability to customize a network directory, this feature also facilitates network administration as well as provides a more responsive capability to satisfy end-user networking requirements. Enhanced Security A network directory service includes a series of rules that defines how the administration process occurs. These rules can define how users are requested to use the network, how they gain access to different objects, whether or not they can inherit certain permissions to use different objects, and how users authenticate themselves. Through the previously described rules, different security policies can be effected to govern access to the directory service and, once access is obtained, the ability of a user to use network resources. Because a network directory service supports a single point of access, this means that all network access is funneled through the rules that govern security. This in turn makes it easier to protect both access to the network and, once access occurs, the ability of network users to perform a variety of network-related operations. Armed with a general appreciation for the operation, utilization, and key features of a network directory service, one can now focus on Novell’s NDS and Microsoft’s Active Directory. NOVELL’S NDS Novell’s NDS was first introduced with the release of NetWare 4.0. Since that time, NDS has been revised and improved upon, both with the release of NetWare 5.0 and as individual upgrades to NDS. The newest revision to NDS, which represents its eighth version, is available. This revision, which is now referred to as NDS Version 8.0, was in beta testing during mid-1999. This new version of NDS is backward compatible with prior versions of NDS, yet is far more scalable than previous versions. Under NDS Version 8.0, support is provided for one billion objects per tree as well as the most recent version of the Lightweight Directory Access Protocol, LDAP Version 3.0. Although the number of NDS releases appears considerable, the major structure and core components associated with this directory service have not changed, with each release building on those core components. NDS consists of a core series of five components that are listed in Exhibit 30-2. By examining each of the core components, one can obtain an appreciation for the operation of this network directory service. 376

The Evolving World of Network Directory Services Exhibit 30-2. NDS Core Components. • Objects and object management modules • Distributed database operations • Novell Directory Access Protocol • Schema • Supporting services

Objects and Object Management NDS was designed to provide users with a single, logical view of all network resources and services. Resources, which are referred to as objects, are organized in a hierarchical tree structure, with the resulting structure referred to as the directory tree. Because the schema allows the tree structure to be modified, an organization can tailor the arrangement of objects in the tree according to its organizational structure. Under the NDS architecture, an object is contained in an organizational unit (OU). An OU in turn can be contained within another OU, similar to an organizational chart. This feature allows access to different network resources to be performed either on an individual basis or on an organizational basis. For example, consider network users Jane and John in the advertising department at the well-known firm Whoami. Their log-in names could be set to Jane.advt.whoami and John.advt.whoami. Suppose the advertising team requires access to a color laser assigned to the marketing group. The administrator could either grant Jane and John access to the printer on an individual basis, which would require two steps, or grant the entire advertising OU (advt.whoami) access to colorlaser.mkt.whoami, with the latter only requiring a single step. Thus, the preceding example indicates both the flexibility of the use of a directory tree-based directory service as well as how its use facilitates the administrative process. Distributed Database Operations As previously mentioned, NDS directory tree information is replicated on multiple servers, which provide both fault-tolerant log-in operations as well as facilitate network administration. If the primary copy of the tree should become unavailable, either due to a server or communications link failure, the network automatically switches over to use a backup copy of the tree. Because WAN links normally operate at a fraction of the speed of that of a LAN, it is important to obtain the ability to partition a tree in order to place its data closer to users who need its services. NDS permits this, allowing for example the partition of a tree associated with one server to be placed on another server when the sets of users reside on different sides of the WAN. This action enables directory information required by each set of users to be placed on servers local to the users, minimizing directory searching across the lower speed WAN. 377

SECURITY Novell Directory Access Protocol The NDS protocol is referred to as the Novell Directory Access Protocol (NDAP). This protocol is a request/response protocol built on top of the NetWare Core Protocol (NCP). Because NCP is not a transportable protocol, it relies on other protocols to provide for the transmission of packets across a network. Since NCP supports IPX and IP, this means that NDAP and NDS can be used in both legacy Novell environments built on IPX, as well as the evolving industry standard Internet Protocol (IP). Schema The NDS schema consists of a set of rules that governs the structure of the directory tree, defining such parameters as how objects are defined, which attribute values can be associated with an object, and similar characteristics that define how the directory can be used. To facilitate directory operations, the schema requires every object in the directory to belong to an object class. Because attributes are associated with an object class, this allows attributes for a group of objects to be set with one operation, which can considerably facilitate the administrative process. Under NDS, a schema maintenance utility, referred to as Schema Manager, permits administrations to easily modify the operational schema. Through the use of Schema Manager, one can review, modify, print, compare, extend, and diagnose the NDS schema. Supporting Services NDS includes a variety of supporting services interfaces. Such services allow NDS to be integrated with other network or operating system services. One example of an NDS supporting service is for the Simple Network Management Protocol (SNMP). NDS can be configured to support SNMP, which enables this directory service to interact with an SNMP agent supported by the host operating system. Through this interaction, it becomes possible to view NDS SNMP-managed objects through an SNMP management console. A second example of NDS supporting services is NDS Event Services. NDS Event Services enable the monitoring of NDS activity on an individual server. Through NDS Event Services, one can track local events as well as certain types of global events. In addition, event services can be configured to notify a NetWare Loadable Module (NLM) during or after the event, permitting Novell or third-party products to be used to generate e-mail messages, page an administrator, or perform other functions. Other examples of NDS supporting services include support for Unicode, auditing, tracing, and logging certain NDS events. In addition to the previously mentioned supporting services, it should be mentioned that 378

The Evolving World of Network Directory Services NDS includes several configuration and maintenance tools. Configuration tools assist users in installing and configuring NDS when a server is first installed into an NDS tree, while maintenance tools facilitate merging two NDS trees, repairing the local NDS database, and logging and tracing NDS operations. Support for Windows NT No discussion of NDS would be complete without discussing Novell products that enable NT application servers to be integrated with NDS. Novell currently provides two products to integrate NT application servers with NDS: Novell Administrator for Windows NT and NDS for NT. Novell Administrator for Windows NT permits user information to be created and maintained in NDS, which is then automatically synchronized with the NT domain-based network directory system. This results in network users having a single log-in view of the network because Novell Administrator for Windows NT synchronizes user passwords. The second Novell product that provides for the integration of NT application servers is NDS for NT. This product stores NT domain information as NDS data, eliminating the necessity to synchronize Windows NT domain information with NDS. To illustrate the benefit of NT support, assume an employee requires access to both a NetWare server and an NT domain. Without NDS for NT, the network administrator would need to create and maintain two accounts for the employee — one on the NT domain computer and another on the NetWare server. However, if NDS for NT is installed on the NT server, all requests to the NT domain user object for log-in will be redirected to a single user object in NDS which controls access to NT resources. Thus, this action halves the administration effort, which can greatly facilitate the work of the network administrator when the organization has hundreds or thousands of employees. Having an appreciation for NDS, one can now focus on Microsoft’s Active Directory. ACTIVE DIRECTORY Microsoft’s Active Directory represents a new network directory service that is currently in beta field trials. Active Directory is incorporated in the newest version of Windows NT, which at one time was referred to as NT 5.0 and was renamed during 1999 as Windows 2000. Because an understanding of Active Directory is best understood by examining the current method of network directory services supported by Microsoft, this will be done prior to turning our attention to the newer network directory service. Through Windows NT 4.0, the Microsoft network operating system is based on Windows NT Directory Service. Similar to Novell’s NDS, Windows 379

SECURITY NT Directory Service provides a single point of network log-in and administration. However, instead of a hierarchical relationship, Windows NT Directory Service uses a domain model in which trust relationships must be developed to provide a centralized management capability. Under the current Windows NT Directory Service, a domain is a group of Windows NT servers and modes that share a common user account database and security policy. Within a domain, one Windows NT server functions as a primary domain controller (PDC), while other servers can function as backup domain controllers (BDCs). The PDC is responsible for maintaining security and synchronizing security information among other servers on the network. The PDC also replicates its database to the BDCs, enabling a BDC to be promoted to the role of a PDC if the PDC should fail. Unlike NDS, which can support millions and under the soon-to-be released NDS Version 8 billion objects, an NT PDC is limited to 40,000 or fewer objects. While this limit might be efficient for small organizations, if the organization has multiple locations connected by relatively low-speed WANs, they would probably divide their network into multiple domains. However, because the security model of Windows NT Directory Service is based on the domain concept, a user from domain advt will not be able to log on to domain mktg unless he or she is either made a member of mktg, configured to be a member of a global group, or domain advt is configured in a trust relationship with domain mktg. Each of these options can represent a time-consuming task that requires coordination between persons administering each domain, which is the reason why many people refer to the inability of the current NT Directory Service to scale well. This also explains why NDS is currently the preferred network directory service used by many competitive local exchange carriers (CLECs) and Internet service providers (ISPs). With an appreciation for the general operation and limitations of Windows NT Directory Service, one can now focus on Microsoft’s Active Directory. Active Directory represents a hierarchical directory structure that can be divided, similar to NDS, into organizational units for functional or organizational groupings. To facilitate the integration of an existing Windows NT Directory Service, Active Directory permits domains to be interconnected into a hierarchical structure. Active Directory should be capable of storing ten million objects, which is a considerable improvement over Windows NT 4.0 40,000 user limit per domain. The architecture of the Active Directory is as flexible and perhaps more so than NDS, supporting integrated application programming interfaces (APIs) that enable the look-up of e-mail addresses through Microsoft’s Exchange Mail and the support of the Internet domain name services (DNS), which is used as its locator service. That is, in the Active Directory, 380

The Evolving World of Network Directory Services Windows NT domain names represent DNS names and permit a host to have a common address for both Internet and Active Directory usage. PRODUCT COMPARISON Any attempt to compare the actual usage of NDS and Active Directory at this time is on relatively shaky ground as NDS is a viable product that is in use by organizations requiring millions of objects while Active Directory is in beta testing. Although it will probably be a year or more until Active Directory is in use by large organizations that can truly test its capability, there are certain features of Active Directory that may make this network directory service extremely appealing. Those features are in the area of Internet standards support and security. In the area of Internet standards support, Active Directory fully integrates its name space with DNS, which simplifies both object location and access to objects. In comparison, although NDS can be set up to support a “DNS-like” structure, it does not truly integrate its name space with DNS. Thus, NDS can make object naming and access more complex if the administrator used a proprietary naming convention when NDS was installed. Concerning security, NDS used the commercially available RAS public and private key encryption scheme for authentication, and RADIUS for remote access. In comparison, Active Directory supports Kerberos and smart cards. Although the difference between RAS and Kerberos might be similar to the difference between a half dozen and six, the difference between RADIUS and smart cards is more pronounced. The Remote Authentication Dial-in User Service (RADIUS) represents an emerging Internet Engineering Task Force (IETF) standard that is used by some vendors besides Novell for obtaining a centralized point for verifying a user name and password. In comparison, smart cards, while not a standard, are in common use by hundreds of commercial organizations, government agencies, and academic institutions as a mechanism for user authentication. Thus, it might appear that the support of smart-card technology is a more popular choice than RADIUS for remote access. SUMMARY If one is attempting to compare NDS and Active Directory, probably the best decision is to experiment and wait. Because of the importance of a network directory to the operation of an organization, perhaps the best advice this author can make is to test Active Directory and read trade press reports of experiences of other organizations. After all, if NDS is working fine, why risk a stable platform? As one local TV announcer would say, “That’s my opinion — what’s yours?” 381

Section VII

Integrating Legacy Traffic ORGANIZATIONS THAT ARE INTEGRATING THEIR NEW WEB ENVIRONMENTS with legacy hosts, by definition, have legacy traffic to deal with in their networks. In IBM environments, this means that they have SNA applications and SNA traffic that they must integrate with the new intranets that are based completely on TCP/IP. This section provides very pertinent information for those organizations requiring tools that allow them to integrate these two disparate networking environments together. Chapters 31 and 32 provide the business-case elements for transitioning from SNA to TCP/IP and describe the potential steps and technologies to provide that integration. Chapters 33 and 34 describe in more detail the dominant technologies that allow organizations to integrate SNA with TCP/IP.

383

Chapter 31

Integrating Data Centers with Intranets Anura Gurugé

NEARLY ALL ENTERPRISES THAT HAVE MAINFRAMES OR LARGE, NETWORKED AS/400s now have an intranet. Most, in addition, already have a presence on the Internet in the form of a home page, and many are actively exploring the possibilities of using the Internet for electronic commerce, customer support, and as an ultra cost-effective means of global remote access. In parallel, intranet-to-intranet communication via extranets is being viewed as the means of streamlining and expediting enterprise transactions. There is, however, a beguiling disconnect vis-à-vis these new strategic and burgeoning TCP/IP-centric networks and the traditional data center functions that continue to be imperative for the day-to-day operations of these enterprises. Very few enterprises at present have tightly integrated their intranets with their data centers. This is despite the fact that up to 70 percent of the vital data, and many of the mission-critical applications required by these enterprises, are still likely to reside on their mainframes or AS/400s. That is akin to baking an apple pie with no apple filling. Integrating an intranet with a data center is not simply a matter of implementing TCP/IP on a mainframe or AS/400 along with a Web server. Many of the host-resident, mission-critical applications still required were developed, typically 15 years ago, such that they only work in Systems Network Architecture mode. The nearest that one can come to making theses applications TCP/IP compatible is to use them in conjunction with a hostresident or “off-board” tn3270(E) (or tn5250 in the case of AS/400s) server that will perform standards-based SNA-to-TCP/IP protocol conversion. Otherwise, the applications will have to be rewritten to work in TCP/IP mode. This is not feasible because the cost and effort of doing so for the $20 trillion installed base of SNA mission-critical applications would make all the tribulations associated with the Y2K challenge appear trivial! 385

INTEGRATING LEGACY TRAFFIC While some of the data center-resident data could be accessed using an Open Database Connectivity type scheme, this is certainly not true for all of the data center resources. Some data, especially if stored on “flat files” or nonrelational databases (such as IBM’s still widely used Information Management System), can only be accessed via SNA applications. In other instances, the data make sense only when combined with the “business logic” embedded within an SNA mission-critical application. In addition to these crucial SNA applications, there is inevitably a large installed base of SNA-only “legacy” devices such as IBM 4700 Financial Systems, automated teller machines, and control units that still need to be supported. Thus, there is a need for explicit SNA-related technologies in order to get the most from your host vis-à-vis your intranet. The good news is that highly proven and stable technology from more than 40 credible vendors including IBM, Cisco, Attachmate, OpenConnect Systems, Wall Data, Eicon, Novell, WRQ, Farabi, Client/Server Technology, Sterling Software, Blue Lobster, etc. is now readily available to facilitate data-center-to-intranet integration in a seamless and synergistic manner. Enterprises around the world such as GM, FedEx, Ohio State University, Royal Jordanian Airlines, Nestlé, The Chickering Group, National Van Lines, the State of Idaho, Al Rajhi Banking & Investment Corp. (Saudi Arabia’s largest bank), and Gazprom (a $30 billion natural gas company in Russia) are already gainfully using this intranet-to-data-center integration technology on a daily basis for business-critical production use. Al Rajhi Bank, for example, uses browser-based access to SNA to provide home banking, while GM, National Van Lines, Royal Jordanian Airlines, and The Chickering Group use it to permit agents to access applications or databases resident on mainframes or AS/400s over the Internet. INTRANET-TO-DATA-CENTER INTEGRATION TECHNOLOGIES To be viable, integration technologies need to be able to accommodate an extremely broad and disparate population of client equipment and functionality, including PCs, UNIX workstations, coax-attached 3270/5250 terminals, printers, minicomputers, SNA applications that communicate program-toprogram using LU 6.2 or LU-LU Session Type 0-based protocols, SNA-only devices, SNA-LAN gateways (e.g., NetWare for SAA), and legacy control units. The PCs, workstations, and printers may work in either SNA or TCP/IP mode. Consequently, one will need SNA access technologies to deal with TCP/IP clients, particularly PCs and workstations, and SNA transport technologies to deal with SNA-only clients. The most pertinent technologies are: • SNA access technologies that permit non-SNA clients to gain access to SNA applications: — ip3270/ip5250: the use of existing PC/workstation SNA emulators (e.g., Attachmate EXTRA!Personal Client) and existing SNA-LAN 386

Integrating Data Centers with Intranets gateways (e.g., Microsoft’s SNA server) with proprietary encapsulation schemes for conveying a 3270/5250 data stream within TCP/IP — tn3270(E)/tn5250: IETF standard that enables TCP/IP clients (e.g., Attachmate EXTRA!Personal Client) to access SNA applications via tn3270(E) (e.g., IBM 2216) or tn5250 servers — Browser-based access with 3270/5250-to-HTML conversion: thin-client solution where a server-resident SNA-Web gateway performs 3270/5250 data stream-to-HTML conversion replete with some amount of user interface rejuvenation so that SNA applications can be accessed directly from a browser — Browser-invoked Java or ActiveX applets: dynamically downloadable applets, which can optionally be cached on a PC/workstation hard disk, that provide 3270/5250 emulation either directly or in conjunction with an intermediate SNA-Web gateway — Browser-invoked applets as above, but with user interface rejuvenation — Application-specific Web-to-data-center gateways, e.g., IBM’s CICS Web Interface or Interlink’s ActiveCICX — Programmatic (or Middleware) Servers, e.g., IBM’s MQSeries, Blue Stone’s Sapphire/Web, or Blue Lobster’s Stingray SDK • SNA end-to-end transport: — Data Link Switching: ubiquitous, standards-based encapsulation scheme performed by bridge/routers that permits any kind of SNA/APPN traffic, independent of session type, to be transported end-to-end across a TCP/IP WAN. Desktop DLSw (DDLSw) is also available where SNA traffic can be encapsulated within TPC/IP at the source PC — High Performance Routing-over-IP: alternative to the DLSw championed by IBM, whereby SNA-oriented routing is performed across IP — AnyNet: IBM protocol conversion technology, integrated within IBM server software including Comm. Server/NT and OS/390 as well as within some SNA/3270 emulation packages, that converts SNA message units into corresponding TCP/IP packets The three transport technologies ensure that the still large installed base of SNA devices and control units are able to communicate with mainframeor AS/400-resident SNA/APPN applications across an intranet using SNA on an end-to-end basis. Of the three, standards-based DLSw, which is available on nearly all major brands of bridge/routers, is by far the most widely used and the most strategic. AnyNet, in marked contrast, is not available on bridge/routers or within SNA devices such as 3174s, 4700s, etc. Consequently, it cannot be used easily as a universal scheme for supporting any and all SNA devices and control units as can DLSw. Thus, AnyNet is not as strategic or useful as DLSw. High Performance Routing (HPR) is IBM’s follow-on architecture to APPN and SNA. HPR-over-IP, now available on IBM 387

INTEGRATING LEGACY TRAFFIC 2216 and CS/NT, has irrefutable advantages over DLSw: it can support native, data-center-to-data-center SNA/APPN routing over TCP/IP; SNA LU 6.2 class-of-service (COS)-based path selection; and traffic prioritization. If and when this technology is more readily available, corporations that require SNA/APPN routing to obtain optimum traffic routing in multidata center networks, or those that have LU 6.2-based applications that rely on COS, may want to consider HPR-over-IP as an alternative to DLSw. DLSw’s ability to support any and all types of SNA/APPN traffic effortlessly could be easily abused when trying to integrate intranets with data centers. DLSw could be used all by itself to realize the integration by grafting the existing SNA/APPN network, totally unchanged, onto the intranet through the extensive deployment of DLSw all around the periphery of the intranet. This brute-force, “no SNA-reengineering whatsoever” approach has been used in the past to integrate SNA networks into TCP/IP networks. With this type of DLSw-only network, one would find SNA-LAN gateways being used downstream of the intranet, and then DLSw being used to transport the SNA output of these gateways across the intranet. While such networks indubitably work, there are other strategic techniques such as a 3270-to-HTML and applet-based 3270/5250 emulation that should typically be used in conjunction with DLSw to achieve the necessary integration. Exhibit 31-1 summarizes how the various SNA Transport and SNA Access integration techniques can be gainfully synthesized to integrate data centers with intranets. TOO MUCH CHOICE IS THE BIGGEST HURDLE The availability of seven very different SNA access solutions is indeed one of major distractions in the intranet-to-data-center integration process. However, having such a wide range of solutions is also beneficial and should be gainfully exploited. With the solutions at hand, one can tailor highly effective and pragmatic configurations where different access solutions are employed, depending on both the requirements of the end user, and whether the access is across an intranet or the Internet. Exhibit 31-2 provides guidelines as to how the various access solutions can be best deployed. The following is a comprehensive list of all the SNA access-related components that may be required to integrate an intranet to a data center, grouped, where appropriate, into “functional” classes: • Web server: to download applets or HTML-converted 3270 screens • Web browser: for browser-based access • Client software other than the Web browser: — full-function, 3270/5250 emulator for ip3270 or ip5250 — tn3270(E) or tn5250 client 388

Integrating Data Centers with Intranets

Exhibit 31-1.

Synthesizing SNA Transport and SNA Access integration techniques.

PCs, Macs, workstations

• Browser-based • tn3270/tn5250 • ip3270/ip5250 • Programmatic

If a “full-stack” SNA/3270 emulator is currently installed: • DLSw • DDLSw • AnyNet • HPR-over-IP

Network computers

• Browser-based • Programmatic

SNA-only devices

• DLSw • HPR-over-IP

Remote SNA-LAN Gateways

Eliminate the remote gateway and opt for ip3230/ip5250, tn3270/tn5250, or browserbased access

Prior to gateway elimination: • DLSw • HPR-over-IP

Devices that work in SNA or TCP/IP mode

• Convert to IP and then use TCP/IP-based access schemes • tn5250/tn3270 • Programmatic

If the device cannot be converted to TCP/IP: • DLSw • AnyNet • HPR-over-IP

— terminal (and printer) emulation applet, with or without interface rejuvenation capability — programmatic client, which could be in the form of an applet — optional, very small (e.g., 5K) “keyboard support” applet used by some 3270-to-HTML conversion solutions (e.g., Novell’s HostPublisher) to overcome the problem that browsers currently do not support all the function keys found on a PC/workstation keyboard • TCP/IP-to-SNA gateway: — SNA-LAN gateway for ip3270/ip5250, such as Microsoft’s SNA Server, located on a PC server or a channel-attached controller such as Bus-Tech’s NetShuttle — tn3270(E) or tn5250 Server, located on a PC server, bridge/router, channel-attached bridge/router, channel-attached controller, or mainframe • SNA-Web gateway: for applet-based solutions either to augment the applet’s functionality, provide security features, or both. Examples include Attachmate’s HostView Server and OCS’s OC://WebConnect Pro. Typically resident on an NT or UNIX server, although OCS has a version, it has an integrated TCP/IP-to-SNA gateway functionality that runs on a mainframe • 3270-to-HTML or 5250-to-HTML gateway 389

INTEGRATING LEGACY TRAFFIC

Exhibit 31-2. Deploying the Best Access Solution. Intranet Interim

Mid-term

The Internet Interim

Mid-term

Employees: • Data entry

tn3270(E)

Browser: tn3270(E) emulation

• Power user (e.g., programmer)

ip3270

ip3270

• Senior management; queries, e-mail, calendar …

ip3270

Browser: with rejuvenation, or programmatic

• Professional: < 2 hours/day mainframe access

tn3270(E)

Browser: some rejuvenation, or programmatic

• Professional: > 2 hours/day mainframe access

ip3270

Browser: some rejuvenation, possibly programmatic

• Telecommuter

Browser-based access

• Mobile user

Browser-based access

• “Agent” working for the company; e.g., dealership, travel agent

Browser: tn3270(E) emulationcached applet

Browser: rejuvenation either with applet or 3270-to-HTML

Public: • Simple query

Browser: 3270-to-HTML

• Insecure, multistep query

Browser: 3270-to-HTML with some form of screen sequencing

• Secure, multistep transaction

Browser: applet with rejuvenation

• Application-specific Web gateway: for example, IBM’s CICS Internet Gateway or CICS Gateway for Java • Programmatic server: an external, server-resident component required for certain programmatic access schemes Of the seven access techniques, ip3270/ip5250 and tn3270(E)/tn5250 represent the “old guard,” well-known and widely deployed schemes employed 390

Integrating Data Centers with Intranets

Exhibit 31-3.

Pros and cons of traditional emulation approaches.

ip3270/ip5250

tn3270(E)/tn5250

Pros

• In most cases, works with existing 3270 emulators and SNA-LAN gateway configuration, in which case a good tactical solution • Total support for all terminal emulation and workstation customization features • Extensive support for printing • Support for LU 6.2 • Support for other emulator-provided application APIs • Availability of channel-attached SNALAN gateways, e.g., Bus-Tech NetShuttle • Wall Data plans to have an applet that talks ip3270

• Widely adopted industry standard • Highly scalable tn3270(E) servers available on mainframes and channel-attached routers (e.g., Cisco 7xxx/CIP) • tn3270/tn5250 is the underlying “applet-to-gateway” protocol used by many browser-based access solutions, including IBM’s “Host-onDemand” and WRQ’s Reflection EnterView • Efficient, nonverbose protocol • Deemed by all to be a strategic technology for building SNA-capable i•nets • Enjoys both vendor and customer mind-share

Cons

• Proprietary protocol • No mainframe-resident gateways • Not promoted by any vendors — although this is probably an oversight because many forget the distinction between tn3270 and ip3270 • Client emulator may be more expensive than a tn3270 client • Most customers do not understand that this is an option open to them • No standard encryption schemes

• No support for LU 6.2 as yet • Printing options not as extensive or flexible as that potentially possible with ip3270/ip5250 • Cannot match ip3270 when it comes to the esoteric, power-user-oriented terminal emulation and customization features • Unlikely to support the application APIs supported by ip3270 emulators • Any end-to-end encryption available is going to be vendor specific or realized through the use of virtual private networks (VPNs)

by over 20 million users. The best way to put these two techniques in context is to look at their pros and cons as shown in Exhibit 31-3. Browser-based Access via 3270-to-HTML Conversion Browser-based access to SNA applications was initially made possible in late 1995 by 3270-to-HTML conversion. With HTML being the native language for creating Web pages, converting 3270 data stream to HTML and vice versa was the obvious, logical, and most straightforward way to Webenable SNA applications. Alluding to the fact that Web site and Web page creation is often referred to as “Web publishing,” 3270-to-HTML conversion came to be known as “host publishing,” with many product names such as Attachmate’s HostPublishing System, Farabi’s HostFront Publishing, Novell’s HostPublisher, and IBM’s Host Publisher feature in Ver. 6.0 of CS/NT amplifying this theme of how host (i.e., SNA) data can now be readily 391

INTEGRATING LEGACY TRAFFIC

Exhibit 31-4.

Typical architecture of 3270-to-HTML conversion.

published on the Web. Exhibit 31-4 shows the general architecture of a 3270-to-HTML scheme. 3270-to-HTML has two incontrovertible advantages over that of an applet-based, “green-on-black” emulation approach: 1. It only requires a browser at the client end. This obviates any and all issues related to applet download time and the time taken to establish a persistent end-to-end connection between the applet and the pertinent data center component. Eliminating the need for an applet also makes 3270-to-HTML essentially browser-agnostic. 2. It always delivers at least a “default” amount of user interface rejuvenation. It is referred to as “Auto GUI,” e.g., background and Web page-like “trench” input fields. Extensive rejuvenation is possible, usually with the aid of visual programming tools such as JavaScript, Jscript, or Microsoft’s Active Server Page technology. 3270-to-HTML is, thus, ideally suited for Internet-based SNA access, particularly to permit the public casual access (e.g., querying the delivery status of a package) to mainframe or AS/400 applications. Not having to download an applet will expedite the access process, while the rejuvenation capabilities will protect the innocent from the brutalities of the “greenon-black” screens. 3270-to-HTML used to get short shrift because the early implementations did not have good, cogent answers to issues such as session integrity, end-to-end persistence, file transfer, function key support, light-pen support, etc. Some of these limitations were due to shortcomings of the browser or the HTTP protocol. The good news, however, is that some of today’s implementations, for example Novell’s intraNetWare 392

Integrating Data Centers with Intranets

Exhibit 31-5.

The Sterling Software VM:Webgateway-based architecture of the 3270-to-HTML solution used by Lafayette Life Insurance.

HostPublisher and Eicon’s Aviva Server, have gone to great lengths to come up with innovative but pragmatic solutions to nearly all of these previous limitations. Take the sacrosanct session integrity and “persistence” issue. HostPublisher, through the use of session IDs, screen sequence numbers, timeouts, and unique “session name” validation (as opposed to IP-address-based correlation) can persuasively circumvent most, if not all, of the “horror” scenarios that could potentially occur given that 3270-to-HTML solutions do not maintain an end-to-end persistent connection à la applet-based solutions. Exhibit 31-5 shows the actual architecture of a mainframe-centric 3270-to-HTML solution actively used by Lafayette Life Insurance (Lafayette, IN) to provide 1000+ field agents, as well as corporate staff in Indiana, real-time, online access to policy information via the Internet. Exhibit 31-6 weighs the pros and cons of such a solution. Browser-based Access Using Applets for 3270/5250 Emulation Applet-based access schemes have the inalienable advantage that they provide a near complete “green-on-black” tn3270(E)/tn5250 emulation scheme, replete with TCP-based, end-to-end persistent connections in the form of a dynamically downloadable “thin client.” Distributing and, moreover, maintaining 3270/5250 emulation and tn3270(E)/tn5250 clients, especially given the incessant barrage of updates for such software, had become a costly and time-sapping endeavor for most SNA shops. Once 393

INTEGRATING LEGACY TRAFFIC

Exhibit 31-6.

Pros and cons of Lafayette Life Insurance 3270-to-HTML solution.

Pros • Only requires a browser at the client side • Works with “any” browser given that there are no applets or JVMs involved • A client platform-agnostic solution in that this access scheme will work on any platform that can run a Web browser • Facilitates and forces user interface rejuvenation • Able to automatically exploit any standard, server-to-browser security schemes, including end-to-end encryption à la SSL V. 3.0 • Relatively simple, cost-effective solution that can be easily implemented on a PC server • Ideal for enabling Internet users to gain casual access to SNA applications Cons • Most solutions do not support function keys and light pens since browsers do not currently recognize those items • No SNA-specific printing or file transfer—with printing typically limited to screen printing functions provided by a browser • Cannot deal with unsolicited screens from an application • Schemes to ensure data integrity and session security in the absence of end-to-end persistent connections are implementation-specific, with some implementations being significantly better than others • Rejuvenation schemes, although typically using off-the-shelf products such as JavaScript, are implementation-specific with no real commonality between the various products • Corporate users, who require access to SNA applications and other Web information concurrently, need to open multiple browser windows • Some solutions may only support a few hundred concurrent SNA sessions per server

host printing, IND$FILE-based file transfer, and cut-and-paste between windows was in place by Spring 1998, applet-based emulation was a tempting proposition. It delivered tn3270(E)/tn5250 functionality, albeit by some esoteric and little-used 3270 graphical capabilities, in the form of a browserinvoked “thin client.” In addition, it promised the possibility of user interface rejuvenation via drag-and-drop tools, Java-based APIs, rules-based systems, or Visual Café-type applet programming. Versions 4 or greater of Netscape and Microsoft Internet Explorer permit both Java and ActiveX applets to be cached on the hard disk of a PC/workstation. Caching eliminates the need for an applet to be downloaded from a Web server each time it is invoked. Caching, however, does not compromise the version control and automatic software update advantages of downloaded applets. With cached applets, a Web server is still 394

Integrating Data Centers with Intranets automatically queried each time the applet is invoked to determine if there is a newer version of the applet. If there is, the user is given the option of dynamically downloading it. Cached applets thus provide users as well as network administrators with the best of all worlds—automatic version control without the continual wait for an applet to be downloaded. A browser user invokes a terminal emulation applet by clicking on a “button” on a predesignated Web page in much the same way that 3270-toHTML conversion is invoked. A key difference, however, is that there is no “script” per se, as is the case with 3270-to-HTML. Instead, the applet is embedded within the Web page. Invoking the applet causes it to be activated. The applet may either be downloaded from the Web server hosting the “mother” page that has the applet embedded, or be started up from a cached version following a quick version validation. Today, most of the applets perform a tn3270(E) or tn5250 client emulation, with Wall Data’s Cyberprise Host Pro and Farabi being in the minority in that they work with SNA-LAN gateways rather than just tn3270(E) servers. Nearly all of the SNA access applets were Java-based at the beginning. Now, however, some vendors such as Attachmate, Wall Data, and Farabi are offering both ActiveX and Java applets. Most of the applet solutions open up a separate emulation window alongside the browser window rather than having the emulation screen appearing as a “pane” inside the browser window. The advantage of keeping the applet emulation window separate is that it does not block the browser from being used for other purposes. Thus, the browser is not locked into an SNA session, as is the case with 3270-to-HTML conversion. Note, however, that regardless of whether the applet window runs alongside or within the browser, today’s SNA access solutions invariably rely on a virtual machine provided by the browser, as opposed to the operating system, on which to run the applet. This means that the applet window will be abruptly and unceremoniously terminated if the browser hosting that applet is closed. An SNA access applet could, in theory, be converted and made to run as an application on a virtual machine provided by the operating system if one really wanted to eliminate dependence on the browser. Quite a few of the applet-based emulation schemes require an intermediate SNA-Web gateway between the applet and the tn3270(E)/tn5250 server. Providing security, both in terms of authentication and encryption, is the overriding rationale for these intermediary SNA-Web gateways, so much so that, if an applet-based access scheme does not use an intermediary server component, one needs to start thinking immediately of auxiliary security measures such as VPN. (See Exhibit 31-7) This will, however, change in the future when native end-to-end encryption is added to the tn3270(E) standard.

395

INTEGRATING LEGACY TRAFFIC

Exhibit 31-7.

Pros and Cons of the Applet-Based Emulation Scheme.

Pros • Powerful terminal emulation comparable to tn3270(E)/tn5250 clients • “Thin-client” solution that minimizes software distribution and maintenance cost and effort, with the added attraction of cache-able applets • Support for host printing à la tn3270(E), IND$FILE file-transfer, and cut-and-paste between windows • Applet window can run alongside browser, thus leaving the browser window free for other interactions • End-to-end persistent connections ensure data integrity and session security • Encryption possible when an SNA-Web gateway is used • Java applets facilitate cross-platform portability Cons • Rejuvenation only possible with certain solutions • Encryption contingent on the presence of an SNA-Web gateway • Potential delays when the applet is being downloaded, when caching is not used • Most solutions currently only support Java applets • May not work with “older,” e.g., Ver. 3, browsers

The Bottom Line Proven technologies now abound to facilitate intranet-to-data-center integration. Some of these technologies, such as DLSw and tn3270(E)/tn5250, are standards-based, mature, and very widely used. Even newer technologies such as browser-based access are now being field tested and increasingly heavily deployed. Technology is not a barrier when it comes to intranet-to-data-center integration. The one distraction could be that there is too much choice, but that should not be used as an excuse; it is more an opportunity. One will require multiple access options and at least one transport scheme to satisfactorily meet every need. The technology and the products are here today to ensure that one has plenty of flexibility and variety in choosing that solution set.

396

Chapter 32

Gracefully Transitioning from SNA to IP: Why, How, and When? Anura Gurugé

WHEN EVALUATING THE MERITS AND IMPLICATIONS OF TRANSITIONING TO TCP/IP-CENTRIC IT INFRASTRUCTURE, it helps to reflect on the tale of

A

the Great King Canute of England and Denmark (c. 1016) who tried to demonstrate to his adoring subjects that there were powers that even he could not control by showing them that he was powerless to stop the tide from coming ashore. Just as was the case with PCs and LANs, TCP/IP is now an unstemmable technological tide; possibly even a tidal wave. Whether one likes it or not, relishes it or fears it, TCP/IP is here to stay — and will dominate worldwide computing for at least the next two decades, thanks to the endorsement and kudos it gets on a daily basis as the sustaining force behind the Internet miracle. Mainframe shops today cannot claim unfamiliarity with TCP/IP. Without exception, corporations that use mainframes for their MIS now have a TCP/IP-based intranet in addition to their traditional SNA/APPN or multiprotocol-oriented enterprise network. Most, furthermore, already have a presence on the Internet in the form of a home page, and many are actively exploring the possibilities of using the Internet for electronic commerce, customer support, public relations, product promotions, and global remote access. Not missing out on the tantalizing potential of E-commerce over the Internet is indubitably the most pressing MIS issue that is being discussed at the highest levels of corporations, starting in the board room. In parallel, intranet-to-intranet communications via extranets are being viewed as the most effective means of streamlining and expediting enterprise-to-enterprise transactions. All of this intranet and Internet (i.e., i•net) 397

INTEGRATING LEGACY TRAFFIC activity means that TCP/IP is already being widely used alongside mainframe-based computing systems. Installing TCP/IP on a mainframe these days is not a difficult, nerve-racking, or laborious undertaking. Extensively proven, extremely efficient, highly scalable, and extremely reliable TCP/IP stacks for mainframes are readily available. IBM claims that more than half of the mainframes running MVS or OS/390 already have TCP/IP installed. Installing TCP/IP on a mainframe facilitates its integration with intranets or the Internet; permits fast, high-speed bulk data transfers with TCP/IP clients or other systems; and, moreover, positions it as a data server for Web-based applications. Once TCP/IP is installed, one could, if required, even have the mainframe acting as a high-capacity Web server. There are companies, such as $9.5B Lafayette Life Insurance (Lafayette, IN), that already have Web servers running on their mainframes — which in the case of Lafayette happens to be an IBM 9672-R24, 3rd generation CMOS-based S/390 Parallel Enterprise Server. There are significant strategic and tactical advantages to going ahead and installing TCP/IP on a mainframe and moving toward a TCP/IP-centric computing environment. For a start, it provides a solid basis for any and all E-commerce-related initiatives. It can also reduce, sometimes quite significantly, overall capital and operational costs. For example, the browser-based access to SNA solutions that are now readily available from over 40-odd credible vendors for providing unrestricted SNA terminal access across i•nets, totally eliminate the considerable cost associated with installing, managing, and periodically upgrading SNA/3270 emulation software on each and every PC/workstation that needs access to SNA applications. Using TCP/IP all the way into the mainframe, and then performing SNA conversion at the mainframe per the tn3270(E) standard, also ensures that one no longer needs highly expensive, SNA-oriented communications controllers like the 3745 or the 3746-950. Instead, one can profitably utilize high-performance, low-cost, channel-attached routers such as the IBM 2216-400, Cisco 7500/CIP, or Cisco 7200/CPA as the means of interconnecting the mainframe to the network. Then there are networking-related cost savings. With a TCP/IP-centric infrastructure, one can, albeit with the appropriate security measures (e.g., firewalls), gainfully use the Internet as a way to realize extremely cost-effective remote access for far-flung remote offices, agents, telecommuters, and overseas distributors. Intranets, given that they are based on widely available commodity technology, are also invariably less costly to implement than comparable SNA/APPN or multiprotocol networks. Exhibit 32-1 illustrates a TCP/IPcentric environment. 398

Gracefully Transitioning from SNA to IP: Why, How, and When?

Exhibit 32-1.

TCP/IP-centric environment. Clients have access to both TCP/IP and SNA resources across an intranet as well as the Internet.

DISPELLING YOUR CONCERNS Before the advantages of moving to a TCP/IP-centric infrastructure with TCP/IP on the mainframe are articulated any further, it is best to allay any concerns one may have about moving away from SNA. • Security is no longer the roadblock it used to be with highly proven, bulletproof TCP/IP-specific security solutions for mission-critical commercial computing systems. • Total unencumbered access to mission-critical SNA/APPN applications running on mainframes or AS/400s is in no way compromised, jeopardized, or even inconvenienced by the installation of TCP/IP on a mainframe and the standardization on a TCP/IP-centric infrastructure. There are a plethora of well-established, standards-based SNAto-TCP/IP integration technologies, such as tn3270(E) and Data Link Switching (DLSw), that ensure unrestricted SNA access and end-toend SNA transport across TCP/IP networks. • Installing TCP/IP on a mainframe and using a TCP/IP-centric i•net for all mainframe access does not prevent one from having ACF/VTAM on that same machine as well. Therefore, one can continue to have the same level of APPN/HPR support that is on one’s mainframe today to guarantee that mission-critical SNA/APPN applications will continue to work without any problems. 399

INTEGRATING LEGACY TRAFFIC • Today’s TCP/IP stacks for mainframes deliver exceptional throughput and are highly optimized to maximize efficiency and scale easily to support tens of thousands of concurrent users. TCP/IP is not the CPU hog that it was portrayed to be a few years ago. Mainframe TCP/IP is so efficient these days that some corporations run, without any difficulty or degradation in overall performance, multiple stacks on the same mainframe to gain added throughput and ensure that different applications (e.g., FTP and tn3270(E)) can each have their own dedicated stack. • Incisive, sophisticated, and comprehensive TCP/IP-based network, application, TCP/IP-stack, and system management is now possible with mainframe-resident management systems such as Interlink’s eControl. e-Control provides TCP/IP-centric management tools and facilities for problem determination, performance management, change management (i.e., the configuration and administration of mainframe TCP/IP resources), and capacity planning. • With today’s mature router technology, it is now possible to realize TCP/IP-based networks that are sufficiently resilient and robust to provide high-availability networking with uptimes in excess of 98(+) percent. Today’s TCP/IP-centric networks are significantly more reliable and stable than the bridge/router-based multiprotocol networks currently used for transporting SNA/APPN traffic. • Traffic prioritization between different classes of applications vis-à-vis the TCP/IP network is no longer an issue with today’s router software offering functions such as Quality of Service (QoS), Bandwidth Reservation Protocol (RSVP), and highly customizable queuing schemes (e.g., Cisco’s Custom Queuing). For those few situations where there is a need to support SNA LU 6.2 class-of-service (COS) prioritization on an end-to-end basis, IBM offers a scheme known as Enterprise Extender that permits APPN/HPR routing across IP. • The continued presence of ACF/VTAM on the mainframe alongside TCP/IP ensures total, uncompromised support for parallel sysplex operation — including multi-node persistent sessions (MNPS), workload balancing, and generic resources. • High-performance, highly efficient, full-duplex TCP/IP transfers across ESCON channels is not a problem with the TCP/IP-specific CLAW protocol that permits two subchannels to be grouped together for highthroughput and simultaneous bidirectional communications. If anything, TCP/IP channel transfers are significantly faster than SNA/APPN transfers with both IBM or Cisco channel-attached solutions such as the IBM 2216-400 and the Cisco 7500/CIP. • Mainframe-based TCP/IP printing is not an impediment with tn3270(E) now supporting host print, and with products such as Interlink’s very comprehensive Enterprise Print Services (EPS). 400

Gracefully Transitioning from SNA to IP: Why, How, and When? CASE AGAINST A LAST-MINUTE SNA REVIVAL Despite the daily mounting evidence to the contrary, there are still some who believe that IBM will not allow SNA/APPN to succumb to IP, and that there will be a concerted attempt to reestablish SNA/APPN-based networking. IBM recognizes that the role SNA/APPN plays in the future will be restricted to the mainframe in the context of mission-critical applications, and that TCP/IP, unassailably, will be the networking fabric of the future. The following four examples alone should convince the reader that IBM is not just reconciled to, but is in reality one of the greatest advocates of, TCP/IP-centric networking. • In June 1998, IBM announced an ESCON channel-attachment capability for its flagship 12.8Gbps throughput 8265-17S Nways ATM Switch, which can support 622Mbps ATM uplinks. The only protocol supported across this channel attachment is IP. • In March 1998, IBM discontinued the 2217 Nways Multiprotocol Concentrator, which was an APPN/HPR-based router that permitted TCP/IP, IPX/SPX, and NetBIOS to be routed end-to-end across an SNA network. The 2217 was the antithesis of a conventional TCP/IP-based router. By discontinuing the 2217, IBM tacitly admitted that there was no call or future for IP-over-SNA routing. • IBM is avidly promoting the notion of APPN/HPR-over-IP routing with its Enterprise Extender technology, which is now available on the IBM 2216, 2212, and 2210. Cisco, Bay/NT, and others are expected to also support this capability. By promoting the notion of routing APPN/HPRover-IP, which is the exact opposite of the routing scheme employed by the 2217 that IBM discontinued, IBM is making it very clear that the only WAN networking role it sees for APPN/HPR in the future is within the context of it being used on top of IP. • The IBM 2216-400 can be attached to an IBM 3746 via an expansion chassis known as the Multi-Access Enclosure (MAE). If one only wants to transfer IP traffic into the mainframe, MAE offers a native, highspeed coupling facility between the 2216-400 and the 3746. If one insists on wanting support for SNA, the best that IBM can offer is a dual Token Ring connection between the 2216-400 and the 3746. When factoring this in with the 8265 IP-only channel-attachment scheme discussed above, it becomes clear that IBM is already positioning itself for an era when most of the mainframe channel traffic is IP based. THE PRIMARY ADVANTAGES OF MOVING TO MAINFRAME IP • Enables seamless integration of one’s fast-growing intranet with one’s mainframe, given that at least 70 percent of the corporate data that one’s in-house intranet users require is still on a mainframe rather than on a Web server, NT server, or UNIX system. 401

INTEGRATING LEGACY TRAFFIC

Exhibit 32-2.

Ohio State University Diagram. Existing and prospective students are provided with access to mainframe-resident SNA applications over the Web using a totally TCP/IP-centric infrastructure, including TCP/IP and tn3270(E) server on the mainframe.

• Decisively positions one to exploit all the rich potential of E-commerce over the Internet by ensuring that all of the applications and data one may require to enable such commerce is now TCP/IP-ready and can be easily integrated with the necessary Web technology. Business-to-business E-commerce over the Internet is expected to be in excess of $30B by the year 2002. • Permits one to exploit the Internet as an extremely low-cost means of realizing global remote access to mainframe applications including all mission-critical SNA applications, as shown in Exhibits 32-2 and 32-3. In addition to browser-based access, extremely secure virtual private networking (VPN) solutions — such as those provided by Interlink’s NetLOCK V.2.0 — can be used to realize enterprise-specific remote access over the Internet. • Facilitates and expedites the File Transfer Protocol (FTP)-based file downloads and uploads that one is likely now doing on a daily basis with all of one’s distributed servers. • Allows one to quickly open up mainframe applications for new, Internet-based services such as home banking, online investment, personal travel reservation, and Web-based status checking (e.g., querying the status of an expedited mail item or a cargo shipment), as demonstrated in Exhibit 32-4. • Greatly minimizes the cost of SNA access by being able to use tn3270(E) or browser-based access to SNA solution. The browser-based access 402

Gracefully Transitioning from SNA to IP: Why, How, and When?

Exhibit 32-3.

A totally TCP/IP-based system. This system is currently being tried out by a $18B U.S. conglomerate to ensure that telecommuters and mobile users around the world have access to mainframe-resident SNA applications across the Internet.

Exhibit 32-4.

Actual screen shot of a rejuvenated 3270 user interface. This was used by a mainframe-centric, Internet-based home banking system realized using browser-based access in the form of 3270-to-HTML conversion.

solutions will eliminate the considerable costs associated with installing, managing, and regularly updating SNA/3270 emulation software on individual PCs/workstations by using either an applet-based scheme, where the applet is dynamically downloaded from a Web 403

INTEGRATING LEGACY TRAFFIC

•

• •

•

•

server, or a 3270-to-HTML conversion scheme, as shown in Exhibit 32-4, which only requires a browser to be present within the client PC/workstation. Enables one to quickly phase out the very expensive, SNA-oriented IBM 3745 or IBM 3746 communications controllers in favor of high-performance, low-cost channel gateways such as the IBM 2216-400, Cisco 7500/CIP, or Cisco 7200/CPA. Permits one to use the mainframe as a high-capacity, very low-cost-peruser Web server for intranet, extranet, or even Internet applications. Greatly simplifies the integration of mainframe data with the new Web applications that are being developed using tools such as NetDynamics 4.0, Bluestone Sapphire/Web, and ColdFusion. Eliminates the need for external, low-capacity tn3270(E) gateways such as Microsoft’s SNA server by using integrated, highly scalable, mainframe-resident tn3270(E) servers such as the one included within Interlink’s e-Access TCPaccess TCP/IP software. Gain better channel throughput by using TCP/IP across the channel to a mainframe-resident tn3270(E) server. Phase out the cost and complexity of doing business-to-business transactions using SNA Network Interconnection (SNI) by moving toward a secure, low-cost extranet scheme.

PROVEN TECHNOLOGY TO FACILITATE THE TRANSITION FROM SNA TO IP The good news is that highly proven and stable technology, from over 40 credible vendors, including Interlink, Cisco, OpenConnect Systems, IBM, Attachmate, Wall Data, Eicon Technology, Novell, Farabi Technology, Client/Server Technology, Blue Lobster, etc., is now readily available to facilitate TCP/IP on the mainframe and the standardization on a TCP/IP-centric networking infrastructure — although one still relies on quite a few mainframe-resident, mission-critical SNA applications. The technologies available will enable one to integrate the current SNA/APPN-based environment with the new TCP/IP-centric world in a seamless and synergistic manner. Athough it may feel like it, one will not be a lone pioneer beating across hitherto uncharted territory. The move from SNA to IP is happening with accelerating pace around the world. In reality, this transition has been happening for the last few years. Enterprises around the world — such as GM, FedEx, Sabre/American Airlines, The Library of Congress, Ohio State University, Royal Jordanian Airlines, Nestles, The Chickering Group, National Van Lines, the State of Idaho, Lafayette Life, Lincoln National Reinsurance, Swiss Air, Al Rajhi Banking & Investment Corp. (Saudi Arabia’s largest bank), and Gazprom (a $30B natural gas company in Russia), to name but just a few — have already started to integrate their data center resources with TCP/IP-centric i•nets. Exhibit 32-5 illustrates the solution deployed by Lincoln National Reinsurance. 404

Gracefully Transitioning from SNA to IP: Why, How, and When?

Exhibit 32-5.

Mainframe TCP/IP-based system. This system is being used by Lincoln National Reinsurance Companies, one of the largest reinsurers in the world, to provide its account reps with up-to-date client information across the Web.

To be of use, the technology that enables the transition from SNA to IP needs to be able to accommodate an extremely broad and disparate population of client equipment and functionality. Just some of the entities that need to be dealt with vis-à-vis this transition include PCs; UNIX workstations; coax-attached 3270/5250 terminals; printers; minicomputers; SNA applications that communicate program-to-program using LU 6.2 or LU-LU Session Type 0-based protocols; SNA-only devices (e.g., IBM 4700 Financial Systems); and legacy control units. The PCs, workstations, and printers at remote sites may work in either SNA or TCP/IP mode. Consequently, one will need SNA access technologies to deal with TCP/IP clients, in particular PCs and workstations, and SNA transport technologies to deal with SNAonly clients. This is not a problem. Today, there is a wealth of solid, wellestablished, field-tested technologies to realize both SNA access and SNA transport in the context of mainframe TCP/IP — and a totally TCP/IP-based network. Some of the key technologies that will permit an easy transition from SNA to IP include: • tn3270(E): widely used, nearly ten-year-old IETF standard-based access scheme that enables low-cost TCP/IP clients to access SNA applications via a mainframe-resident tn3270(E) server. Today, tn3270(E) is 405

INTEGRATING LEGACY TRAFFIC

•

•

•

•

•

•

being used by over ten million SNA users. tn3270(E) clients are ubiquitously available from all of the traditional SNA/3270 emulation vendors. All examples shown in Exhibits 32-2, 32-3, and 32-5 utilize tn3270(E) in some form. Browser-based access with 3270-to-HTML conversion: a thin-client solution (as shown in Exhibit 32-2) where a server-resident SNA-Web gateway performs 3270 datastream-to-HTML conversion, replete with some amount of user interface rejuvenation, so that mainframe SNA applications can be accessed directly from a browser across an i•net. The rejuvenated user interface for home banking (shown in Exhbit 32-4) was realized using 3270-to-HTML conversion. Secure Sockets Layer (SSL)-based authentication and encryption, as available with contemporary browsers, is used with this scheme to provide end-to-end data encryption. Browser-invoked Java or ActiveX applets: dynamically downloadable applets that can optionally be cached on a PC/workstation hard disk, and that provide tn3270(E) client emulation. This was the technique used in the system shown in Exhibit 32-3. User interface rejuvenation, as well as end-to-end data encryption, is also possible with this technique. Application-specific Web solutions: such as Interlink ActiveCICX, IBM CICS Web Interface, Interlink ActiveIMX, and Interlink OPEN-IMS, that expeditiously integrate mainframe-resident applications with the Web. Programmatic (or middleware) solutions: such as IBM MQSeries, Blue Stone Sapphire/Web, or Blue Lobster Stingray SDK, etc., that permit mainframe applications to be interfaced with TCP/IP or Web applications. Data link switching: like tn3270(E), is a ubiquitous, IETF standardsbased encapsulation scheme performed by bridge/routers that permits any kind of SNA/APPN traffic, independent of session type, to be transported end-to-end across a TCP/IP WAN. DLSw ensures that any kind of legacy SNA device or application can be nondisruptively and gracefully accommodated within a TCP/IP-based infrastructure High-performance routing-over-IP: an alternative to DLSw championed by IBM whereby APPN/HPR-oriented routing is performed across IP. This scheme has the advantage over DLSw in that it can permit APPNbased routing between multiple data centers, and is capable of supporting LU 6.2 COS prioritization on an end-to-end basis over an IP network.

By using one or more of the above technologies, one can gracefully transition from SNA to IP without losing the services of any current missioncritical SNA/APPN applications, sacrificing any functionality, or compromising security or reliability. 406

Gracefully Transitioning from SNA to IP: Why, How, and When? THE BOTTOM LINE With the rapid growth of intranets and the daily increasing significance of the Internet as the next frontier for commerce, the hold that TCP/IP has on commercial sector networking continues to solidify. Even IBM has acknowledged that the role of SNA, APPN, and HPR is going to be relegated to the mainframe as the basis for mission-critical applications. Many of the concerns that MIS professionals had in the past about TCP/IP — such as its security, reliability, and efficiency — are no longer germane. Solid and highly proven TCP/IP solutions are now available from multiple vendors for all aspects of mainframe-oriented computing — whether it be TCP/IP stacks, tn3270(E) servers, security packages, management platforms, applications, channel gateways, or network infrastructures. There really are no impediments to transitioning from SNA to IP. Thousands of companies around the world have already started to standardize on an end-to-end, mainframe-to-PC, TCP/IP fabric. Increasing numbers have already started to use the Internet for remote access and information dissemination. The technology required to successfully and gracefully transition from SNA to IP — such as tn3270(E), browser-based access, and DLSw — is here, is widely available, is cost-effective, and is remarkably solid. E-commerce beckons. What are you waiting for?

407

Chapter 33

One Corporate Network — Dream or Nightmare? Donna Kidder

FOR THE LAST DECADE, MANY ENTERPRISES HAVE HAD SEPARATE TCP/IP AND SNA NETWORKS. The SNA network handled most mission-critical traffic, while the TCP/IP network carried much of the internal communication — e-mail, file transfers, design specifications, HR data, etc. While maintaining two separate networks is expensive, the benefit of consolidation is always weighed against the cost of degrading the performance of the SNA network. Fear of network degradation and loss of application availability kept many enterprises from consolidating their networks — no one wanted to risk their business on experimental technologies. Well, it is finally safe to go in the water. The technologies for network consolidation have matured and have been proven in thousands of production networks. These enterprises are enjoying the cost benefits of network consolidation while actually improving SNA network response time and availability. There are several technologies that allow network consolidation, but the most commonly implemented technology is Data Link Switching (DLSw). However, DLSw lacks some key functionality that is only present in Advanced Peer to Peer Networking (APPN). This chapter describes both of these technologies, their strengths and weaknesses, and offers recommendations on when and where to use each of them. DLSw DLSw is a technology created by the APPN Implementors Workshop (AIW) in 1995 and documented in IETF RFC 1795 and RFC 2166. DLSw provides a standard means for routers to transport SNA data across an IP backbone. The DLSw standard uses TCP as a reliable transport for SNA traffic and calls for local termination of the link layer protocols at either end of the 409

INTEGRATING LEGACY TRAFFIC TCP pipe, as shown in Exhibit 33-1. The standard also defines how DLSw routers communicate with each other to locate resources, establish endto-end circuits, and address congestion. It defines the frame formats, state machines, and includes media considerations (SDLC and LLC2). The focus of the standard is to ensure interoperability, so it includes a capabilities exchange. Using this capabilities exchange, different vendors’ implementations can support additional features without impacting their ability to interoperate with other standard implementations. What are the benefits of DLSw? First of all, DLSw enhances availability for SNA and NetBIOS traffic. DLSw was the first standard technology to enable nondisruptive rerouting around link failures for SNA traffic. Because the data is transferred in TCP/IP, if a link fails, IP automatically reroutes around the failure. Today’s IP routing protocols can reroute within 2 to 15 seconds, so the failure is typically not noticed by an SNA end user. If a frame is dropped in transit, TCP automatically retransmits it, ensuring that no data is lost. DLSw also eliminates link-layer timeouts. Failure of a DLSw endpoint is disruptive (just as failure of an FEP is disruptive), but recovery is immediate and dynamic. DLSw simplifies network design by separating the media from the protocol. With DLSw in place, SNA traffic can flow over any combination of campus or carrier technologies, and SNA end systems on disparate media can communicate. DLSw also enables enterprises to leverage state-of-the-art TCP/IP infrastructures and technologies. Once SNA is encapsulated in TCP/IP, intermediate networking gear treats it like TCP/IP and it benefits from all the technology available today. Intermediate Layer 3 switches can process it. It can be compressed, encrypted, accounted for, and even transported over the Internet.1 The name “data link switching” is significant. DLSw defines a means to switch SNA traffic between data links. The data link protocols themselves are terminated at each end. This provides two key benefits: • It eliminates the issue of link-level timeouts and nonproductive polling traffic on wide area links. • Disparate media can be connected, simplifying network design. With DLSw, one can now enjoy the benefits of attaching via Token Ring at the data center while deploying lower cost Ethernet or maintaining the install base of SDLC controllers at remote sites. This is because DLSw uses a standard media-independent frame format to transfer data between data link switches. The link-layer headings are not added until the data is ready to be dropped on a link. Hence, one can connect remote Ethernet- or SDLC-attached devices to a front-end processor (FEP) over Token Ring. Several enterprises use Token Ring as a means to attach to FEPs because it simplifies FEP configuration 410

One Corporate Network — Dream or Nightmare?

Exhibit 33-1.

Conceptual view of DLSw.

and allows for load balancing and automatic backup2 — either of an FEP or a Token Ring interface coupler (TIC). DLSw is inherently scalable in a hierarchical SNA network.3 It relies on the scalability of TCP/IP, which is the same technology used in the largest network in the world — the Internet. And scaling TCP/IP in a hierarchical setting is vastly easier than scaling the Internet. Many networks with thousands of remote sites simply use static routes with defined backup paths. In hierarchical SNA networks, broadcast replication is not an issue. Even if it were, DLSw uses a minimum of broadcasts on the wide area by caching information as it is learned. The key processing load for a DLSw router is LLC2 processing and traffic forwarding. LLC2 timers can be tuned to minimize their impact on central site routers. If the number of SNA physical units (PUs) in the network and the traffic load at the data center are known, then one can determine fairly safely how many central site routers are required to handle the network. As the network grows, one can simply add additional central site routers and balance traffic across them. In general, the number of PUs connected to a single router is more likely based on how many eggs one wants in one basket and not on router capacity. Finally, DLSw is a relatively simple technology. To implement DLSw, it is key to understand LLC2 and SDLC, but it does not require an extensive knowledge of SNA. What are the implications on the corporate intranet? When DLSw is implemented, a single TCP/IP infrastructure can support both SNA and IP. All SNA traffic is carried inside of TCP/IP frames; so once the traffic is encapsulated, any intermediate IP router or switch can forward the packet, providing network design flexibility. Routers and switches can distinguish DLSw traffic from other TCP/IP traffic by its unique port number. This is 411

INTEGRATING LEGACY TRAFFIC important if SNA traffic needs to be prioritized enroute. Only one routing protocol is required to reroute around failed links, minimizing duplicate and unnecessary routing updates. Besides technology, one must also look at DLSw from a business perspective. DLSw leverages the vast skill base of TCP/IP — key with the cost of skilled people increasing and the pool of knowledgeable people in SNA decreasing. DLSw is the premiere SNA integration technology in use today, with well over 450,000 routers deploying it. This fact is key when comparing technologies based on stability, maturity, and the simplicity of integrating two disparate networks after an acquisition. Finally, for most enterprises, the corporate direction for the network is TCP/IP. DLSw allows the network migration to proceed while continuing to provide a transport vehicle for SNA traffic — which is sure to exist for many years to come. So what are the downsides? • In parts of the world where bandwidth is at a premium, the overhead introduced by DLSw must be considered. It adds a 40-byte TCP/IP header to every packet, and a 16-byte DLSw header. • In addition, while DLSw eliminates disruptions caused by link failures, it may add a point of failure in the network (unless the DLSw router is placed in front of an FEP instead of being used as an alternative to an FEP). • Finally, the DLSw standard does not support SNA class-of-service (COS).4 SNA class-of-service allows prioritization of SNA traffic. For example, interactive SNA traffic can be prioritized ahead of batch SNA traffic. How important is COS? It depends. In a traditional (subarea) SNA network, COS is only supported between SNA nodes — that is, FEPs. Remote SNA controllers and gateways (defined as PU Type 2s) do not understand COS. FEPs can prioritize traffic on their outbound queues based on transmission priority, but remote SNA controllers and gateways cannot prioritize inbound traffic. The bigger issue in most networks today is not prioritizing within SNA traffic, but prioritizing between SNA and TCP/IP. APPN APPN is an SNA networking protocol developed by IBM in 1985 (originally for mid-range processors). More recently, APPN has been implemented in VTAM and in all other key communication equipment offered by IBM, including FEPs, 3174s, AS/400s, and the OS/2 Communications Manager. In addition, APPN is implemented in multi-protocol routers from several vendors. APPN is more open than previous SNA protocols. As IBM enhances APPN, the enhancements are offered to the participants in the AIW. Other 412

One Corporate Network — Dream or Nightmare?

Exhibit 33-1.

Conceptual view of DLSw.

and allows for load balancing and automatic backup2 — either of an FEP or a Token Ring interface coupler (TIC). DLSw is inherently scalable in a hierarchical SNA network.3 It relies on the scalability of TCP/IP, which is the same technology used in the largest network in the world — the Internet. And scaling TCP/IP in a hierarchical setting is vastly easier than scaling the Internet. Many networks with thousands of remote sites simply use static routes with defined backup paths. In hierarchical SNA networks, broadcast replication is not an issue. Even if it were, DLSw uses a minimum of broadcasts on the wide area by caching information as it is learned. The key processing load for a DLSw router is LLC2 processing and traffic forwarding. LLC2 timers can be tuned to minimize their impact on central site routers. If the number of SNA physical units (PUs) in the network and the traffic load at the data center are known, then one can determine fairly safely how many central site routers are required to handle the network. As the network grows, one can simply add additional central site routers and balance traffic across them. In general, the number of PUs connected to a single router is more likely based on how many eggs one wants in one basket and not on router capacity. Finally, DLSw is a relatively simple technology. To implement DLSw, it is key to understand LLC2 and SDLC, but it does not require an extensive knowledge of SNA. What are the implications on the corporate intranet? When DLSw is implemented, a single TCP/IP infrastructure can support both SNA and IP. All SNA traffic is carried inside of TCP/IP frames; so once the traffic is encapsulated, any intermediate IP router or switch can forward the packet, providing network design flexibility. Routers and switches can distinguish DLSw traffic from other TCP/IP traffic by its unique port number. This is 411

INTEGRATING LEGACY TRAFFIC APPN, and HPR in particular, have several key advantages. APPN is required to enable use of generic resources in a parallel sysplex complex. The generic resource capability allows one to scale the application processing power by allowing multiple processors to function as one from the perspective of the end user. The end user types in a generic application name (such as CICS), and a coupling facility in conjunction with VTAM finds the processor that is least utilized for the session. The actual session will be with CICS01 or CICS02, for example, but the end user is unaware of the actual application name. HPR is required to take advantage of multinode persistent sessions (MNPS). MNPS takes the parallel sysplex complex to the next level of scalability and availability; it enables nondisruptive rerouting around the failure of the application processor itself. APPN also gives enterprises a choice of how to connect their mainframes to their networks. Once the mainframe access is via APPN, an enterprise is no longer restricted to using FEPs for mainframe access. It can instead use more versatile, faster, and lower cost channel-attached routers. With HPR there are no single points of failures other than the HPR endpoints themselves. If HPR is running in VTAM and in the remote SNA device, then the only way to lose the SNA session is for one of the end-points to go away (assuming there is a path between the nodes). This is definitely the key advantage to this technology. However, APPN and HPR have downsides also. First of all, if a network has a large number of HPR end-points, nondisruptive rerouting may be a moot point. A central site error may cause a significant delay in recovering the network and the end users will more than likely hit CTRL-ALT-DEL, terminating their sessions anyway. Most network administrators would opt for short outages rather than long, nondisruptive recovery cycles during which the network is not available. Most APPN implementations have scalability limitations resulting from directory searches and topology updates. Three-hundred APPN network nodes is about the largest single APPN network one can build. The only way to scale the network beyond 300 is to use a gateway technology known as “border node,” which is currently only available from IBM. Border node — once a function of VTAM only — has been introduced to the AIW, so one can expect to see it on other platforms in the near future, but the technology is in its infancy in the marketplace. APPN networks require careful network design. One needs to worry about the number of network nodes, the number of adjacencies, and the underlying media (not all APPN implementations support all Layer 2 media). APPN takes vastly more SNA knowledge to implement than DLSw. Finally, in terms of performance, APPN prioritizes SNA traffic by COS, but does not prioritize TCP that is intermingled with SNA. When mixing the 414

One Corporate Network — Dream or Nightmare? two on the same link, APPN performance will tend to degrade. The key reason is that APPN is a well-behaved protocol; in periods of congestion, APPN slows down. When APPN slows down, TCP sees more bandwidth and hence will speed up, resulting in a downward spiral of SNA performance. Even in a pure HPR network, the HPR congestion control mechanism still has kinks that need to be worked out — similar to the TCP slow start problem that was fixed by the IETF a few years ago. What about the backbone infrastructure? Natively running APPN across one’s backbone enables physical consolidation as long as all the routers in the backbone support APPN. APPN and TCP/IP can co-exist as ships in the night. Each runs its own routing update protocol, causing multiple updates for the same physical failure. Switches in the network have to bridge APPN. Looking at APPN from a business perspective and putting technical issues aside, APPN has a relatively small installed base; it is less proven in the marketplace and less likely to have all the kinks worked out. The installed base of HPR is even smaller. SNA skills are becoming a hot commodity due to the reducing size of the skilled resource pool. APPN skills are even harder to find. And if the corporate direction is TCP/IP, HPR is a detour. CONCLUSION Both APPN and DLSw enable network consolidation onto a router backbone, but each technology addresses certain requirements that the other does not, as illustrated in Exhibit 33-3. Some enterprises will implement one technology or the other; but for many networks, the ideal design includes both. APPN is important for many environments — basically, any environment with multiple VTAMs using FEPs for cross-domain session routing today. If it is the last SNA enhancement one makes, do it. One can take advantage of the latest parallel sysplex complex capabilities, while at the same time allow for improvement in SNA application availability. However, it is not necessary to put APPN everywhere to gain the benefits of APPN. The key advantages to APPN require that it be run in the data center. One should also run it in distribution routers — either at the main site or at remote sites where there previously had been FEPs. This minimizes the number of HPR nodes in the network , thereby minimizing HPR recovery time and VTAM processing. It also minimizes the impact of any single failure. In addition, this design provides the highest availability where one needs it, allowing the network to recover quickly and nondisruptively from failures in the data center itself. Use DLSw to transport SNA traffic from remote sites to distribution routers. DLSw enables a single integrated TCP/IP backbone that carries both IP 415

INTEGRATING LEGACY TRAFFIC

Exhibit 33-3.

Comparison of APPN and DLSw.

Feature

DLSw Standard

APPN

Nondisruptive recovery from link failures

Yes

Yes, with HPR

Intermediate points of failure

Yes, DLSw routers are intermediate points of failure

With HPR, it is possible to have no intermediate points of failure, although recovery times may be long

Recovery time from any single failure

Implementation dependent, but generally under a minute

With HPR in VTAM, depends on the number of RTP connections; can be in excess of 10 minutes

Consolidated layer 2 backbone

Yes

Yes

Consolidated layer 3 backbone

Yes

No

Routing protocols in consolidated network

Single routing protocol (IP)

Multiple routing protocols (IP and APPN)

SNA routing

No

Yes

Quality of service

Implementation dependent, typically distinguishes DLSw from other traffic by TCP port number

Supports SNA COS to distinguish within SNA, but does not prioritize SNA with other protocols; implementation-dependent extensions are required

Scalability

Up to thousands of DLSw peers in a hierarchical network

Maximum of around 200 NNs in a single network

Installed base

Installed in thousands of networks

Installed in hundreds of networks and/or data centers

Knowledge required to implement

Link layer protocols for SNA, DLSw protocol

Extensive knowledge of both subarea and APPN for most environments

and SNA traffic. Once this infrastructure is in place, costs are minimized (both carrier and management), and migration toward future Web-enabled mainframe applications is simplified. While this design does not eliminate single points of failures, it may in fact speed recovery from failures in large networks. Exhibit 33-4 illustrates a network that leverages the best of both technologies.

416

One Corporate Network — Dream or Nightmare?

Campus network or corporate backbone APPN

APPN

DLSw

Exhibit 33-4.

DLSw

Using APPN and DLSw to leverage the strengths of each.

Notes 1. One enterprise actually connects a manufacturing site in Australia to a European HQ over the Internet simply to avoid the cost of carrier facilities. In this case, connectivity is the key requirement and the ability to control response time is not cost-justified. 2. Token Ring, in conjunction with source route bridging, allows concurrently active duplicate addresses in the network. 3. Most SNA networks are hierarchical. Traffic goes from remote sites to centrally located data centers. 4. Vendor-specific implementations are available that understand SNA COS and map it to TCP/IP type of service.

417

Chapter 34

Enterprise Extender: A Better Way to Use IP Networks Richard J. Tobacco

MOST BUSINESSES RELY ON LEGACY APPLICATIONS RESIDING ON MAINFRAMES. Access to these applications and databases was through networks based on Systems Network Architecture (SNA). Newer application development is often aimed at E-business, and these applications are generally based on TCP/IP networks. Initially, business created and supported these SNA and TCP/IP networks separately. Today’s cost-conscious network managers are seeking ways to consolidate their SNA traffic onto the TCP/IP network. Rewrite of the estimated $3 billion investment in legacy SNA-based applications is clearly not justified. Many businesses use tn3270(E) as their method of accessing those SNA applications. The tn3270(E) client communicates over a TCP/IP network to a tn3270(E) server that transforms the IP data-gram into an SNA data flow. The tn3270(E) server can be located within the application server, on a device channel attached to the application server, or on a branch office router. Unless the tn3270(E) server resides within the application server, there is an SNA data flow between the tn3270(E) and application servers.1 This SNA data flow can be transported across an IP network. In 1992, IBM introduced Data Link Switching (DLSw) as a means for transporting Systems Network Architecture (SNA) data across a TCP/IP network. As the only nonproprietary TCP/IP encapsulation scheme, DLSw2 gained widespread acceptance by all routing vendors, and many customers use this as their method for accessing SNA applications across a TCP/IP network. Five years later, IBM created Enterprise Extender as an open alternative way to integrate SNA applications onto an IP network. Recently, Cisco Systems, Inc., announced3 that its routers will also provide the enterprise extender function — called SNA Switching Services (SNASw).

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

419

INTEGRATING LEGACY TRAFFIC Enterprise Extender is a network integration technology that provides the flexibility to build the networks that cost-conscious network managers demand. It is a technology that extends the reach of SNA applications and data across IP networks to IP-attached clients, while providing users with the levels of reliability, scalability, and control they have come to expect from mission-critical SNA-based applications. Enterprise Extender provides this integration using standard IP technology and requires no new hardware or software in the IP backbone network. The following is a quick look at the nomenclature of protocol transport and some of the differences between DLSw and Enterprise Extender. TALKING TRANSPORT A few transport analogies may aid network managers trying to describe the transport differences to fellow workers. By Air, Land, or Sea: Link Selection Companies have long had the option of selecting the mode of product shipment. Perishable goods might go by air, “normal” deliveries by truck, and bulky products via barge or container ship. SNA provides a similar selection; part of class-of-service, where different types of data can be transported across different links, for example, satellite, modems, or fiber. The capability to select network links based on application-specified class-of-service is only provided by SNA networking. Recent Internet Engineering Task Force (IETF) work on Differential Services has improved the ability to affect the link selection; however, Enterprise Extender allows the link to be selected. Taking Familiar Routes: Connection Oriented One drives to a favorite vacation spot along familiar roads, not altering one’s route unless an unexpected detour is encountered. One knows the travel time and progress toward the final destination is readily apparent. If delayed, concerned friends might be able to ascertain one’s progress by checking at one’s favorite “stopping spots.” In networking terms, one is connection oriented.4 Had one been out joyriding and decided the route at each intersection, one would (in networking terms) be connection-less. Data path consistency, provided by a connection-oriented network, provides similar benefits to network managers. They can view data progress, check for congestion roadblocks, and monitor and plan for increases in traffic. High-performance routing (HPR), a lower-overhead less-complex SNA, creates connection-oriented networks by providing the data path information to the routers and virtually eliminating router overhead for the SNA sessions. With Enterprise Extender, HPR-capable end-points provide connection-oriented routes for the UDP/IP datagrams forwarded by the intermediate network routers (see Exhibit 34-1). 420

Enterprise Extender: A Better Way to Use IP Networks Exhibit 34-1. SNA and TCP/IP Transport. • First versions of SNA, designed to support networks with unreliable links, were very tightly coupled with data integrity checked at each path step. Improved link quality enabled SNA to be restructured with data verification only at the end-points. This advanced SNA — High-Performance Routing (HPR) — separates transport functions from data integrity functions. • The similarity of HPR — an improved Advanced Peer-to-Peer Networking (APPN) SNA routing protocol — with TCP/IP may be apparent; end stations ensure data integrity and intermediate devices forward traffic. The intermediate — Automatic Network Routing (ANR) — nodes forward packets, have no session awareness, and rely on the end-points for error recovery. The end-point — Rapid Transport Protocol (RTP) — nodes provide end-to-end error recovery, nondisruptive rerouting, and selective retransmission of lost packets. People familiar with TCP/IP networks will relate RTP to the TCP portion and ANR to IP part of the TCP/IP stack. Both transports are valid and leading networking products will continue to support TCP/IP and SNA. • A key difference between SNA and TCP/IP transport is that HPR sessions use the same path as long as it is available, whereas TCP/IP sessions may often change paths. Because the HPR end-points establish a path and maintain it until a failure occurs, the intermediate routing devices use routing information contained within the transmitted packets. This eliminates the need for the routing devices to make routing decisions. If there is a path change, the packet labels are changed by the RTP end-points. • Separating transport and integrity functions also means that SNA messaging characteristics can be applied to SNA applications crossing an IP network. Enterprise Extender code provides priority queuing for SNA sessions, making IP transport appropriate for business-critical applications.

First Class or Coach: Priority Queuing We have become accustomed to priorities in business. CEO air-travel arrangements are made first; they travel first class and avoid having to wait in long lines boarding or exiting the aircraft. Likewise, some data transmissions are more important to a business than others. Being able to assign priority based on the data type (e.g., interactive or batch) can mean business-critical data gets transmitted first. Access devices such as routers often create queues for data placed on the network. And IP networks can provide type-of-service (TOS) or port prioritization such that both SNA networks and the new application transport, Enterprise Extender, can provide priority transmission throughout the entire network. Registered Shipments: Reliable Transport Many have sent or received registered mail. At transfer points, the mail (or contents of a shipment) is accounted for prior to being forwarded. This additional effort of accounting for shipment integrity often results in slower and more costly delivery. If one generally finds that “normal” shipments reach their destination, one will rely on the final recipient to verify shipment integrity, thus reducing the cost of shipment. In TCP/IP networks, registered 421

INTEGRATING LEGACY TRAFFIC shipments are analogous to reliable transport and “normal” shipments are comparable to unreliable transport.5 Network links have become more reliable and transmission error rates have declined significantly. Although it was more efficient, if not necessary, for SNA to verify message integrity at each transfer node in the 1960s, it is now possible to avoid the cost of additional processing overhead. Enterprise Extender uses unreliable UDP transport for forwarding SNA application data across a TCP/IP network. Message integrity is guaranteed by the session end-points instead of each intermediate router within the network. Packaging: Encapsulation In networking parlance, placing a letter in an envelope is encapsulation. The envelope has an external address that is used by a carrier to route the letter to its destination. Once received, the envelope is discarded and the contents distributed as appropriate. DLSw is the encapsulation of SNA protocols within a TCP/IP “package.” The package is a usable TCP/IP address that has been discovered by the DLSw-capable routers. Likewise, Enterprise Extender is the transport of SNA protocols within a “lighter” UDP package. WHAT IS ENTERPRISE EXTENDER? Enterprise Extender is an extension to HPR technology that provides efficient encapsulation of SNA application traffic within UDP frames by HPR-capable devices at the edges of an IP network. To the IP network, the SNA traffic is UDP datagrams that get routed without hardware or software changes to the IP backbone. The Enterprise Extender session is “normal SNA” with predictable performance and high availability. Unlike gateways, there is no protocol transformation and, unlike most common tunneling mechanisms, the encapsulation is performed at the routing layers without the overhead of additional transport functions. Enterprise Extender enables efficient use of the IP infrastructure for support of IP-based clients accessing SNA-based data. Enterprise Extender is currently supported on all IBM Communication Servers and routers, on IBM Personal Communications products (tn3270(E) client), on Cisco routers (as SNASw), and within the operating system of System/390 servers.6 Enterprise Extender can be implemented in traffic consolidating communications servers or remote routers or within a single end user’s Personal Communications product. Terminating this traffic within a System/390 enables pure IP transport by existing routers and eliminates many shortcomings of DLSw TCP encapsulation.

422

Enterprise Extender: A Better Way to Use IP Networks Larger Number of SNA Users At both the sending and receiving locations, DLSw-capable routers terminate the SNA connection and locally acknowledge transmissions. Connection set-up and maintenance is process intensive, involving link-level acknowledgment, TCP retransmit, congestion control, protocol translation, and data store-and-forward. This is a significant router burden even to the more powerful routers. Very often, the expensive data center DLSw router is incapable of supporting more than a few hundred SNA users. Enterprise Extender eliminates the termination and acknowledgment workload, thereby enabling the routers to handle a much larger number of users. Because Enterprise Extender uses end-system to end-system congestion control and connectionless UDP, there are no TCP retransmit buffers, no timers, and no congestion control logic in the router. Because of these savings, the edge routers can concentrate on the job they do best — forwarding packets — rather than providing protocol translation and maintaining many TCP connections. Enterprise Extender allows the existing data center routing platforms to handle larger networks and larger volumes of network traffic. In similar network configurations, the same router has been measured to be up to ten times faster when using Enterprise Extender rather than DLSw. No Single Point of Failure Enterprise Extender leverages the inherent availability features of IP to provide failure-resistant SNA application access. With DLSw, the data center router, where termination and acknowledgment occurs, is a single point of failure. Should this router fail, although an alternate path may exist, all SNA connections would be disrupted and would have to be reestablished. Because Enterprise Extender does not terminate the session flow, it can support the IP reroute capability, maintain the connection, and switch to an alternate path without session disruption. When Enterprise Extender is operating within S/390 Parallel Enterprise Servers (Parallel Sysplex),7 the UDP/IP flow extends into the sysplex. The HPR-controlled session — over an IP network — is from the end user all the way to the application on the server. This provides applications full parallel sysplex support — in the event the original application processor fails, it can move to another processor without terminating the original session. This results in “five nines” availability of the legacy SNA application (99.999 percent availability) running on OS/390 — with no changes to the SNA applications. Enterprise Extender eliminates a TCP/IP network connection into the server with a “stub” SNA session between the gateway routing device and the server. Extending the UDP/IP flow into the S/390 server also eliminates the complexity of multiple gateways each supporting several hundred

423

INTEGRATING LEGACY TRAFFIC tn3270 sessions.8 The data center router or switch can be ESCON channel attached or use the recently available gigabit Ethernet adapter for highspeed IP attachment9 to the S/390 server. And, recent S/390 operating system enhancements have eliminated the single access and further improved TCP/IP stack availability. Traffic Priority Most routers provide some form of prioritized queuing; however, the difficulty has been to properly identify the priority at which an SNA packet should be sent. With DLSw, for example, where traffic prioritization is handled on a link basis, multiple links must be defined to the same SNA device. Other traffic prioritization techniques either have no capability to provide SNA priority, or require guesswork or adherence to addressing conventions. Enterprise Extender ends this guesswork and configuration overhead and provides real priority by mapping the priority of SNA packets to UDP port numbers that routers within the IP network can easily use to properly handle the traffic.10 Efficient Message Sequencing DLSw uses TCP/IP reliable transport to avoid messages arriving at their destination scrambled or out of sequence. This is because although higher layers of SNA could correct scrambled messages, correction can require significant retransmission that would severely impact response times. Enterprise Extender employs congestion avoidance (adaptive rate-based) and selective retransmission of lost packets. When only an occasionally missing message part has to be selectively retransmitted, instead of the missing segment and all segments following it, the HPR-capable end-points manage the retransmission with little effect on response times. Choosing Between Enterprise Extender or DLSw Today there are no ubiquitous network solutions. Thousands of native SNA transport networks have provided unsurpassed reliability and predictability. Emerging E-business opportunities rely on the Internet, intranets, and internal TCP/IP networks. Companies deciding how to merge these SNA and TCP/IP networks should consider both Data Link Switching and Enterprise Extender. Consider the total cost of ownership. Are the routers currently in the network capable of supporting DLSw? Do existing routers have the capacity to handle the increased DLSw workload? Are the current network devices capable of providing HPR support to Enterprise Extender? What is the skill set of the people within the organization? Will education offset any savings in initial purchase prices? How much will it cost to maintain the solution?

424

Enterprise Extender: A Better Way to Use IP Networks Consider implementation implications. Are skills currently available or will they have to be recruited? How long will it take to redesign and upgrade the current network? Does one want to maintain the current IP network without change? Does one want gigabit Ethernet attachment into the S/390 server? Does one want to use tn3270 servers to transform from IP-based to SNA-based data flows? Where will one locate and how will one maintain any tn3270e servers? How will current decisions affect future network plans? How one consolidates the networking will affect future growth and acquisition plans. External E-business customers, business partners, as well as internal executives may see one’s network performance. Therefore, choose wisely — network consolidation decisions will impact business. Notes 1. Enterprise Extender also supports communication between a DLUR and S/390, between APPC applications or between S/390 servers. 2. Although DLSw is nonproprietary (RFC 1795), implementations (such as Cisco Systems Inc. DLSw+) are proprietary. The additional features provided by proprietary extensions are only usable in a single vendor implementation. Multi-vendor DLSw implementations will revert to a restricted base-set of functions. 3. September 7, 1999, News Release: Cisco Introduces an Easier, More Scalable SNA Solution for IP Infrastructures. 4. Technically, the connection-oriented and connection-less definitions depend on the presence of session set-up/tear-down protocol and control blocks within the routing device. The less common descriptor “pinned-route” may be a more acceptable answer. 5. This is TCP/IP network nomenclature only and hopefully the U.S. Post Office will not take offense with the analogy. 6. Enterprise Extender is available on Communications Server for OS/390 V2R6 (or later) as a base component of OS/390. 7. IBM, Parallel Sysplex, and S/390 are trademarks of the IBM Corporation. 8. Communications Server for OS/390 has tested support of 64,000 tn3270 sessions. Continuing the DLSw flow to the S/390 also eliminates the complexity of multiple tn3270-capable routers. 9. The gigabit Ethernet adapter on S/390 servers only supports IP flows. Enterprise Extender is the recommended method of high-speed access to SNA applications. 10. The routers must support TOS or port prioritization. Because segmented packets lose port number prioritization, TOS is preferred.

425

Section VIII

Server Infrastructure SERVERS, WHETHER THEY ARE BASED ON NT, UNIX, OR OS/390, ARE AT the heart of any computing environment. In the world of Web-to-host integration, there are servers that serve as middle-tier devices (e.g., NT servers running gateway software) as well as the destination of the transaction, the host (e.g., the IBM mainframe running OS/390). This section covers a variety of topics relevant to servers in a pure Web environment and servers in a Web-to-host environment. Chapters 35 and 36 provide some good, up-to-date information on selection criteria for E-commerce servers and the current trends in server systems. Chapter 37 provides basic information on Web site design and performance for intranets that applies to both Web-to-host and standard Web environments. Chapter 38 discusses the “new kid on the block” of operating systems, Linux, and it’s role in the Web environment. Chapters 39 and 40 specifically discuss the IBM mainframe and issues related to building high-performance, fault-tolerant Web environments in which IBM mainframes play a dominant role.

427

Chapter 35

Selecting Hardware and Operating System Software for E-commerce Duane E. Sharp

THE GROWTH OF THE INTERNET AS A VIABLE BUSINESS VEHICLE IS ONE OF the phenomena of modern technology and has already had a significant impact on the business community, providing new methods of conducting business on a global basis. The Internet has been described as a “powerful, but elusive new sales channel” for global business because it has the capability to reduce transaction costs, expand markets, improve customer service, and enable unique one-to-one marketing opportunities. It is elusive because start-up costs remain high and product offerings are often not integrated with existing corporate business systems. However, this situation is changing as vendors of hardware and software products are caught up in the business opportunities represented by Internet E-commerce. Predictions on the magnitude of business-to-business E-commerce by the year 2002 vary, and are changing rapidly, as the magnitude and breadth of this new business tool become more widely appreciated and accepted. However, all industry analyst forecasts are in the multi-billion dollar range, with Forrester Research recently coming in at $327 billion. The infrastructure required to conduct E-commerce on the Web already exists in many businesses, where applications such as EDI have been using business-to-business networks for some years. These organizations recognize the significant cost savings and convenience of online business-tobusiness transactions. For suppliers, online commerce can shrink the cost

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

429

SERVER INFRASTRUCTURE of doing business, help target customers more effectively, and help to retain them. EDI has gradually shifted to extranets — networks that open up sections of an enterprise’s intranet to suppliers and vendors. Organizations in a variety of business sectors — automotive, aerospace, etc. — that use this technology are able to handle spare parts orders efficiently, with significant savings in person-hours, as well as reduced communication and paper-handling costs, all of which can lead to enhanced profitability. The Web has become particularly useful for commodity products — computers, software, and electronic products, to name a few. For example, Cisco Systems, a major player in networking products, reports that its revenue from Internet sales increased dramatically, from just 5 percent to 33 percent of its annual sales, since it began selling computer networking products from its Web site in 1996. As Deloitte & Touche pointed out in its “1998 Annual Report on The Software Industry,” the impact of the changes that are now taking place in electronic commerce will be dramatic. New and streamlined supply chains will develop, especially in industries such as manufacturing, where supply chain management is particularly crucial. Labor-intensive tasks like issuing and following up on purchase orders will require fewer people and less paper as business moves ever closer to the long-awaited paperless society. It is important for IT managers to recognize the trends and shifts in technology that will occur over the next few years, to enable them to effectively implement E-commerce systems. This article provides a basis for evaluating some of the current hardware products and operating system architectures offered by vendors for E-commerce applications. Trends in hardware development at the microchip level are discussed, as well as major vendor hardware products that have been optimized to make them efficient in Ecommerce environments. HARDWARE FOR E-COMMERCE Changing Chips Developments in microchip technology are having a significant impact on the architectures that vendors are providing to implement E-commerce applications, as well as placing new demands on software. High-performance RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) chips have reached their limits after supplanting Pentium-based chips in large enterprisewide networks. A new chip, the Merced, being jointly developed by Intel and Hewlett-Packard, may emerge as the chip of the future. Because of these enhancements in chip technology, some industry analysts claim that the typical lead that hardware has on software may double in the next year. 430

Selecting Hardware and Operating System Software for E-commerce Merced is a 64-bit chip, a hybrid of RISC and CISC technology, named IA64 (Intel Architecture 64-bit), and will deliver the best of both RISC and CISC features. This chip will combine RISC-chip performance with X86 compatibility, allowing it to run programs designed for X86 and Pentium computers. Because Merced is still under development, its characteristics will need to be verified under real-world application environments. However, Intel’s market leadership in chip design and its manufacturing reputation have already caught the interest and commitment of major hardware vendors, such as Sun, which plans to port its Solaris operating system to support the Merced chip. Mainframes Coincidental with new developments in chip technology, mainframes are reappearing as a computing force in a new generation of products that could become important elements in the network server world and in E-commerce applications. Some business environments that have retained and upgraded their mainframe platforms are already reaping the benefits these computers can bring to network environments. With their fast response times and capability to process increasingly complex database transactions — a significant requirement in E-commerce environments — these reborn relics from the past are natural platforms for high-volume transaction processing. Software products are now available that can link front-end Windows NT and UNIX servers to legacy systems and databases residing on mainframes. Security improvements are also being developed to meet the requirements of the Internet and extranets, and software products will increase the acceptance of mainframes as enterprise servers suitable for Internet applications. As well as being suitable platforms for intranets and for Web servers, where high volumes of transactions are involved, they are also scalable and provide fast response time for dynamic Web sites and complex database queries. Although security of transactions on the mainframe was an early concern, mainframe vendors are embedding encryption technology into mainframe chips, and some vendors even include a secure Internet firewall in their mainframe operating systems. Vendor Server Products For E-commerce applications, the hardware on which these applications run is an important part of the solution mix, and a few major vendors have adapted their standard hardware offerings to meet the specialized requirements of servers for E-commerce applications. In addition, these vendors have developed core applications and adapted their operating systems to enable E-commerce applications to be run efficiently. Some of the organizations that have already entered the market with hardware products adapted 431

SERVER INFRASTRUCTURE for E-commerce applications are IBM, Hewlett-Packard (HP), and Sun Microsystems. Other hardware vendors, such as Compaq — with its newly acquired Digital Equipment Corp. and Silicon Graphics — are not far behind. For this chapter, the focus is on those vendors that have launched Ecommerce products and have a customer base for these products. Several of these vendors, specifically IBM, HP, and Sun Microsystems, have configured their standard hardware offerings for E-commerce, with bundled software and networking interface capability, as well as other features, such as security, designed to make E-commerce applications run efficiently. The following descriptions of the features of these products provide some points of evaluation for organizations entering the E-commerce arena. IBM. IBM has a range of E-commerce servers, from mainframes to client/server products, configured to provide optimum platforms for E-commerce applications. These products are scalable to meet the requirements of small to large businesses, and run a variety of IBM E-commerce software products — Lotus Domino, Java, and Net.Commerce.

In the mainframe category, IBM offers the S/390, with its operating system, OS/390. The capability to handle thousands of users running E-commerce applications, and to integrate existing databases with the new breed of E-commerce applications, makes this product ideal for large organizations that have significant investments in mainframe computers and legacy systems. The latest generation of mainframes provides improved technology in small cabinet physical configurations, using CMOS (complementary metal oxide semiconductor) chips. Lower production costs for these processors resulted in a dramatic drop in the average cost per MIPS, from $93,000 in 1990 to $7500 in 1997, and the per-MIPS cost is forecast to move even lower as production economies increase. The drawbacks for mainframes in today’s network server environment are the same as they were in the heyday of the mainframe: software costs and upgrades are expensive, largely because software vendors persist in charging mainframe license fees on the basis of processor size rather than on usage, a more logical cost model for this hardware category. Cost of ownership for the new mainframes is about the same or less than for UNIX- or Windows NT-based distributed systems, partly due to economies of scale available with mainframes, but also as a result of the greater administrative costs of client/server systems. Moving down the hardware scale to smaller servers, IBM has three primary offerings, in order of size and capability: the RS/6000, the AS/400e, and Netfinity, each one configured for E-commerce applications such as Lotus Domino and Net.Commerce. 432

Selecting Hardware and Operating System Software for E-commerce In addition to its server products, IBM has “circled” the E-commerce product market with other products — software, communications servers, networking products, storage systems, and printers — all of which add to its product mix and capability to provide complete E-commerce solutions. HP. Hewlett-Packard’s primary E-commerce offering is Domain Commerce, a bundled, scalable software solution for E-commerce applications, running on HP NetServer products, and designed to provide a consistent level of service, handling transaction traffic and user priorities.

Included in the Domain Commerce platform, which is software centric, is a range of software to determine user and service classes; manage peakstage windows; enable customers to centrally manage systems, network, and E-commerce applications, commerce gateway and POS; and provide network security and advanced graphics capability. Domain Commerce includes the following functional modules: • HP ServiceControl: providing server overload protection and customer and transaction prioritization • Domain Management: enabling management of the system, network, and E-commerce applications from a standard browser • VeriFone vPOS: advanced, secure, point-of-sale for Internet payment transactions • OpenPix: imaging software for communications and businesses that want to increase Web-based transactions through image-rich Web sites • Netscape Enterprise Server: an enterprise Web server for business applications, providing Web publishing and document management capabilities Options available with Domain Commerce include storefront software, robust transaction engines, and global business systems, as well as a range of other E-commerce products — high-availability servers, encryption accelerators, and enterprise firewalls — available from HP partners. Domain Commerce will initially be available for the HP UNIX operating system (HP-UX), but will be ported to Windows NT. Sun Microsystems. Sun has focused on the development of applications in the Java language, which it introduced to the industry a few years ago, and has several E-commerce applications running under Solaris, its 32-bit, UNIX-based operating system. Sun has placed considerable importance on the E-commerce market, and has over 300 electronic commerce solutions providers.

Sun’s server product lines — the Netra and Ultra families — are scalable and are designed to support transactions from single users to thousands of 433

SERVER INFRASTRUCTURE users. Security products for these platforms are provided by Sun software partners, configured to meet specific enterprise requirements for secure E-commerce. Sun’s solution providers offer a wide range of functionality to address all requirements for commerce-enabled enterprise, including Internet commerce merchant software, billing and payment systems, security, Internet EDI, search and navigation, profiling and usage analysis, information push, content/Web site creation and management, and document management and workflow. Sun’s E-commerce solutions integrate elements from four major areas: 1. 2. 3. 4.

scalable, high-performance platforms security Java and Java Commerce partner programs and professional services

Java’s ‘Write Once, Run Anywhere’ streamlines software development, and Java Commerce provides a complete Internet-based infrastructure for electronic commerce. It is an open platform that can support all standards and payment protocols running concurrently in the same environment. OPERATING SYSTEM SOFTWARE FOR E-COMMERCE The major hardware vendors referred to above offer their own operating systems, usually variants of UNIX, and application suites for E-commerce environments, either developed by the vendor itself or by software partners. However, major operating system vendors such as Microsoft and Novell, both of which have significant presence in networking environments, will also be active players in the E-commerce marketplace. In the following paragraphs, the E-commerce strategies and operating system environments provided by these two industry leaders in networking and operating systems, are reviewed and compared. Microsoft Windows NT Microsoft owns a large percentage of the network market, and its Windows NT product is growing rapidly against competitors NetWare and UNIX. NT Server had the fastest growth of worldwide software license shipments in 1997, with a 73 percent increase. It was expected to surpass UNIX shipments in 1999 and NetWare in the year 2000, according to a recent IDG study. The importance of E-commerce to Microsoft is reflected in the company’s establishment of The Microsoft Internet Commerce Strategy — a comprehensive mix of servers and tools for the E-commerce environment. This strategy has been implemented by integrating commerce functionality into the Microsoft® BackOffice™ family, to provide a commerce-enabled server 434

Selecting Hardware and Operating System Software for E-commerce back end, running on the Windows NT operating system, and based on three core software products: 1. Microsoft Site Server, Enterprise Edition: for the deployment and management of commerce-enabled Web sites (includes Commerce Server) 2. Microsoft Internet Explorer: a Web browser, for a commerce-enabled desktop 3. Microsoft Wallet: for secure, convenient purchasing, as part of the commerce-enabled desktop Microsoft’s E-commerce Internet strategy includes the integration of its own operating systems and commerce tools offered by its developer partners. Novell Unlike Microsoft, its primary competitor in networking operating systems, Novell has chosen to partner with developers rather than develop its own strategy and core tools for E-commerce. In this context, Novell’s network operating system (NetWare) can be viewed as an “umbrella” under which E-commerce applications developed by its partners will run. With its significant leadership position in the networking market and its large, global customer base, there will undoubtedly be many E-commerce environments operating under the NetWare operating system. However, the position taken by Novell is quite different from the IBM, HP, Microsoft, and Sun Microsystems strategies, which provide those vendors with a significant degree of control over their approach to E-commerce and the development and management of core products for this market. As well, Novell has already had some rearrangement in its partnership relationships in core areas of E-commerce software, which tends to weaken its overall position in this market as it unfolds, reflecting a strategy that has not yet achieved stability. CONCLUSION E-commerce, operating under industry-standard operating systems and integrated with a range of new application software to handle business transactions on the Internet, is a rapidly growing and, as market analyses indicate, a significant thrust in global business activities. For the IT manager, there are a reasonable number of choices available to implement E-commerce, ranging from major vendor hardware and integrated operating system with vendor E-commerce software, and software vendor E-commerce suites and partner software with partner products in special function areas, to the integration of a customer-selected range of E-commerce applications running under an industry-standard network operating system. 435

Chapter 36

Server Issues and Trends, 2000 Howard Marks

LIKE

THE REST OF THE COMPUTING INDUSTRY, THE SERVER MARKET IS

changing at what is apparently an ever-increasing rate. Fortunately this change can be understood, planned for, and, most significantly, taken advantage of by clever network managers. The key is understanding both what one’s medium-term, 12 to 18 months out, needs are going to be and what is coming down the pipe from the industry so one can try to match them up. The authors do not pretend to have a good long-term crystal ball, and will not try to predict what is coming up in this millennium, but we have got a pretty good idea of what’s coming down the pike. While some of the trends identified here are just the PC server manifestations of broader trends that also effect the mid-range, UNIX, and mainframe arenas, this chapter looks primarily at how these trends affect the Intel processor server market. In addition to the general trend in the PC industry for the first-tier vendors (Compaq, IBM, HP, and Dell) to get bigger at the expense of secondtier vendors like AST and NEC, 12 trends can be identified in the server market for the near future. They are: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

8-way Intel multiprocessor systems New processors including Deschutes 64-Bit processors including IA-64 Merced OS trends and updates Web management I2O Hot pluggable PCI Clustering Thin-client support Storage area networks and Fibre Channel drive arrays

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

437

SERVER INFRASTRUCTURE 8-WAY INTEL MULTIPROCESSOR SYSTEMS Give us more processors! As Microsoft and Intel attempt to position their products as true enterprise platforms systems supporting up to four Pentium Pro processors using Intel’s standard support chipset and SHV (Standard High Volume) motherboard, they just do not have the horsepower to compete with either traditional mid-range systems or RISC-based UNIX machines. Microsoft’s answer is Windows NT Enterprise Edition, which adds support for two of this year’s server hardware trends: more-than-4-way multiprocessing and clustering. Hardware vendor solutions range from Compaq skipping Intel’s chipsets and designing their own 4-way systems with larger processor cache to servers supporting even more processors. The trend started early in 1997 with 6-way servers from ALR, now a division of Gateway, and culminated with 10-way servers from Unisys and a raft of announcements of 8-way SMP servers from almost all the first-tier server vendors. This is all part of the industry’s continuing race to bigger and faster systems. It has turned into a great race to build the biggest multi-processor servers. In the UNIX market, Sun Microsystems introduced servers with up to 64 UltraSparc processors. Taking a quick look at the servers announced by major vendors, there are several designs with vendors signing on as OEMs for the various camps. Each of these designs works hard to solve the limitation in the Pentium Pro bus architecture, which provides for only four processors. One of the first to ship was NCR’s OctaScale motherboard used in their WorldMark 4380 server. This design links two 4-processor boards with 200MHz Pentium Pro processors and 512KB or 1MB of cache per processor. DEC’s Digital Server 9100 server also uses this design. Another early shipper was Axil Computer’s Northbridge NX801, which uses a similar architecture that bridges two 4-processor Pentium Pro busses through a custom set of bridge ASICs. Data General’s AV8600 is based on the Axil design and motherboard. The most powerful server, and the Windows NT winner on almost every benchmark to date, is Unisys Corp’s Aquanta XR/6, which supports up to ten processors on two processor cards that each have up to 3MB of level 3 cache. Unisys provides a custom Windows NT Hardware Abstraction Layer (HAL) to support the additional processors. The big winner seems to be Corollary Inc., whose Profusion architecture was so attractive to vendors, including Compaq, who will be offering it as an upgrade to their Proliant 7000, Data General, and Hitachi, that Intel 438

Server Issues and Trends, 2000 acquired the company. Profusion uses three Pentium Pro system busses. Two are dedicated to processors, with the third bridged to the PCI I/O bus. NEW 32-BIT INTEL PROCESSORS INCLUDING DESCHUTES In 1997, server vendors faced an interesting conundrum. Intel’s latest and fastest processor, the Pentium II, was available at speeds up to 300MHz, but Intel, in designing the new Slot 1 interface for this processor, only provided support for single- and dual-processor configurations. Vendors wishing to build enterprise-class servers had to choose between building dual-processor 300MHz Pentium II systems or using a larger number of older Pentium Pro processors which top out at 200MHz. The second generation of Pentium II processors, developed by Intel under the code name Deschutes, differ from the original Pentium II in several ways. The most significant is that the Level II cache in the card package runs at the same speed as the core processor, while first-generation Pentium II processors ran the Level II cache at half-speed. The other major change is in the new Slot 2 connector that brings out the full Pentium Pro bus to support systems with more than two processors. Corollary’s ProFusion architecture is designed around the new Slot 2 interface. Announced for late 1998 were Deschutes processors that have 100MHz external busses, which should speed up server I/O somewhat, and extended MMX processors code named Katmai that have enhanced memory bandwidth. Additional instructions also speed up floating point processing. 64-BIT PROCESSORS Intel’s crowning achievement is the IA-64 (Intel Architecture 64 bit) processor co-developed under the code name Merced by Intel and HP. Expected to offer many times the raw performance of today’s processors, this new 64-bit device is in some ways the Holy Grail of microcomputing. The two companies hope that they will finally be bringing the architectural features of mainframe central processors to the PC chip level. The IA-64 is expected to debut at 600MHz and advance to 1GHz over time. The performance of Merced is expected to exceed a rating of 100, according to the widely used SPECfp95 standard, which rates the processor’s performance in engineering and scientific applications. Currently, the Pentium Pro musters about a 6.70 rating. In addition to a faster clock speed, the chip is expected to execute multiple instructions at one time. The more computer instructions a chip can 439

SERVER INFRASTRUCTURE process simultaneously, the better performance it offers — above and beyond the pure speed that measures how fast each instruction is processed. The chip is also expected to use a new approach to processing instructions called Very Long Instruction Word (VLIW), which packs many instructions together. Merced processors will also be able to directly address 64GB of memory, breaking the 4GB limit on current Intel offerings. OS TRENDS AND UPDATES New versions of both major PC network operating systems, Windows NT and NetWare, were due at the time of this writing. Coincidentally, or not so coincidentally, both are Version 5.0 and both serve to strengthen their prior versions’ respective weaknesses, bringing NetWare and Windows NT even closer together in capabilities. NetWare 5.0, formerly code named Moab, at long last supports TCP/IP without resorting to the inefficient and inelegant technique of embedding IPX packets within IP packets as Novell’s older NetWare IP did. NetWare 5.0, despite the name change back from IntraNetWare, further embraces and supports Internet standards including Dynamic Name Services (DNS), Dynamic Host Configuration Protocol (DHCP), and the Lightweight Directory Access Protocol (LDAP) with integration between Novell’s NDS and DNS. Just as significantly, NetWare 5.0 includes a Java Virtual Machine running at the kernel level. Server-based applications can be written in Java, where older versions of NetWare required some arcane knowledge to create NLMs. In another major change, Novell has discontinued the NetWare Web Server, replacing it with Netscape servers ported to NetWare through the Novell/Netscape Novonyx joint venture. While Novell enhances its support for TCP/IP and server-based application development, Microsoft, which had the lead in these areas, is making long-overdue enhancements to Windows NT’s directory services. Windows NT 5.0’s Active Directory enhances the domain architecture, integrating it with DNS and vastly simplifying the process of defining trust relationships. Active directory supports LDAP, X.500-style naming, a distributed file system that allows users to access data without knowing the physical location and implied trusts. It also supports multiple master replication, replacing the clunky PDC/BDC (Primary Domain Controller/Backup Domain Controller) arrangement of earlier Microsoft network operating systems. Microsoft provided an early developer’s release of 64-bit NT, even as the company struggled to get the second beta of NT 5.0 out the door.

440

Server Issues and Trends, 2000 Both vendors are also adding support for new hardware standards including I2O (Intelligent I/O) and hot-swap PCI. WEB MANAGEMENT Over the past few years, there has been a move from an environment where network managers managed servers by sitting in front of them reading obscure messages from text-based screens to servers that not only track the state of their internal components but will automatically call for help if a power supply or drive in a RAID array fails or the internal temperature rises to unacceptable levels. These management tools, including Compaq’s Insight Manager and Intel’s LANdesk Server Manager Pro, have simplified network managers’ lives significantly. This is especially true for those who need to manage servers in multiple locations. The problem with these tools is that there is no easy way to view the status of multiple servers from different manufacturers or to view both hardware and operating systems data. Each vendor of operating systems, hardware, or management tools has a unique console program one must use to access the data from their application. One of the true benefits of the Internet explosion has been the development of a truly universal client console, the Web browser. Vendors have started adding Web-based management and administration tools to network management tools like Seagate’s Manage Exec, operating systems like Windows NT, and even networking hardware like hubs and routers. Now that most server operating systems include Web servers, one expects this trend will only accelerate. Compaq, Intel, BMC Software, Microsoft, and Cisco have banded together to form the Web-Based Management Initiative. This group promotes the use of two new management-related technologies to provide data modeling, manipulation, and communication capabilities recently outlined at a meeting of the Internet Engineering Task Force (IETF): • HyperMedia Management Schema (HMMS), an extensible data model representing the managed environment • HyperMedia Management Protocol (HMMP), a communication protocol embodying HMMS, to run over HTTP The HyperMedia Management Protocol has been presented to the IETF and is currently under discussion. The HyperMedia Management Schema will be defined, maintained, and evolved by the Desktop Management Task Force (DMTF), pending its approval. The schema will be maintained on a public Web site using specially constructed tools to ensure consistency and longevity of the data model.

441

SERVER INFRASTRUCTURE I2O In the early 1990s, several vendors, led by NetFrame, now owned by Micron Electronics, and Tricord, now strictly in the services business, developed and marketed what were known as super servers. These systems leapfrogged the development of server and PC architecture standards to provide higher I/O performance than was available through the limited architectures of the time. These servers surpassed the performance of standard servers of the day by using proprietary memory and bus architectures and by adding processors to disk controllers, network interfaces, and other I/O components. As the PCI bus increased the performance of standards-based servers, the higher prices and proprietary nature of these super servers were no longer justifiable. A careful examination of today’s 4- and 8-way SMP servers shows that for many applications, they are often processing basic I/O interrupts because their I/O architecture requires that the main processors handle the I/O workload. In fact, the biggest difference between a high-end PC server and a mainframe computer of just a few years ago is not in raw compute performance but in the ability to move data from one I/O device to another. The solution to this problem is to add intelligence to I/O devices and I/O controllers that offloads the processing of interrupts from the main processors. This technique works for mainframe computers and worked technically for the super servers of the past. The key is to avoid the proprietary nature, and therefore higher costs, of the super servers of the past. Learning from past mistakes, industry leaders, including 3Com Corp., Compaq Computer Corp., Hewlett-Packard Co., Intel Corp., Microsoft Corp., Novell Inc., and Symbios Logic Inc., formed the I2 O (Intelligent Input/Output) special interest group (I2O SIG) to design a new architecture for future systems. The I2O specification addresses two key problem areas in I/O processing: • performance hits caused by I/O interrupts to the CPU • the necessity to create, test, and support unique drivers for every combination of I/O device and OS on the market I2O solves the first problem by offloading low-level interrupts to I/O processors (IOPs) designed specifically to handle I/O on each device. The I2O architecture relieves the host of interrupt-intensive I/O tasks, greatly

442

Server Issues and Trends, 2000

Exhibit 36-1.

I2O split driver model.

improving I/O performance in high-bandwidth applications such as networked video, groupware, and client/server processing. It solves the second problem by using a “split driver” model for creating drivers that are portable across multiple OSs and host platforms. With the proliferation of network OSs (NOSs), most notably NetWare 4, Windows NT Server, and UNIXWare, the number of drivers that must be written, tested, integrated, and supported has escalated — one for every unique combination of OS and device. Through the split driver model, I2O significantly decreases the number of drivers required: OS vendors write a single I2Oready driver for each class of device, such as disk adapter, and device manufacturers write a single I2O-ready driver for each device, which will work for any OS that supports I2O. The objective of the I2O specification is to provide an open, standardsbased approach to driver design that is complementary to existing drivers and provides a framework for the rapid development of a new generation of portable, intelligent I/O solutions (see Exhibit 36-1). The I2O SIG now has 135 member companies, including the major server, operating system, network, and disk controller vendors. For more information, see www.i2osig.org. HOT PLUGGABLE PCI Since the dawn of the microcomputer age in 1976, small computers have required that their power supplies be shut down before cards could be

443

SERVER INFRASTRUCTURE added or removed. As many technicians have learned, much to their later chagrin, removing a card from an operating system can cause it to fail the proverbial smoke test, destroying the card, motherboard, or both. As PC servers are being used for more mission-critical applications, the downtime required to swap out or add network cards, disk controllers, or other devices has become increasingly problematic. A group of vendors, led by Compaq, HP, IBM, TI (Texas Instruments), Intel, and Cirrus Logic, have formed the PCI Hotplug workgroup as a subgroup of the PCI SIG to develop a standard for hot swappable PCI cards and systems. The workgroup is working with OS vendors to add their support. The first hot-swappable systems shipped at the end of 1997. Operating system support and I/O controllers are now available. The Hot Swap workgroup has merged with the I2O SIG so future devices should support both sets of features. CLUSTERING Clustering, which one can think of as loosely coupled multi-processing, is simply using several similar or identical boxes to act as one server. Clusters can be used to provide increased performance and increased fault tolerance, or availability. Incremental growth is accomplished by adding more nodes to the cluster. An operating system image and main memory address space exist within each server node, and there are various levels of coupling between the nodes to achieve greater performance. Several different types of cluster systems have been available in the PC server market for a few years, primarily to provide greater availability. To understand clustered systems and their differences, one can divide clusters into three basic classes: • active/standby • active/active • concurrent access Active/Standby Clustering Active/standby clustering provides increased server availability but does not increase performance or scalability. Active/standby clustering has been available for several years from Vinca as their StandbyServer product for Windows NT or NetWare and is now available as Microsoft Cluster Server (codename Wolfpack phase 1), which is included in Windows NT Server Enterprise Edition. Active/standby clustering is generally referred to as “failover clustering” and requires a relatively low-speed interconnect because the volume of communication between servers is fairly low. At most, a 100Mbps interconnect is 444

Server Issues and Trends, 2000 sufficient for failover clustering. One server actively runs the application while the other is ready to take over in the case of failure. While the mean time to repair the failed node may be two hours, failover time may be 10 to 20 minutes. This works for customers who run critical applications but can tolerate some short downtime and who require very cost-sensitive solutions. Server availability is increased without requiring application modifications, but at the expense of redundant server components. Products range from those that provide a small increase in availability at relatively low cost, to products that deliver full fault tolerance at the expense of complete server redundancy. Some more sophisticated products allow one server to stand by for several active servers. Novell’s SFT can be thought of as falling somewhere in between active/standby and active/active clustering. Like active/standby systems, there is no performance or load-balancing functionality, but because both servers do all the processing in parallel, the standby server takes over much faster than in a typical active/standby configuration. Active/Active Clustering Active/active clustering offers scalability, as well as availability, at a smaller cost increment per user than active/standby clustering. This may be done with or without load balancing. Here, the servers are described as loosely coupled. Active/active clustering without load balancing occurs when both systems are running critical applications with their own resources. If one system fails, the users can switch to the remaining system, which takes over. There needs to be a fair amount of excess capacity on both systems, so that performance does not degrade excessively in case of failure. While this is more expensive than an active/standby configuration, more users and applications are being supported. This is more desirable where there are two separate and distinct applications; that is, this configuration is not running the same application on multiple systems. Active/active clustering with load balancing supports running one application on multiple systems. Users and data are partitioned, and, in case of the loss of a node, another node can pick up the users and keep them running. The load balancing is manual and requires that the data and users can be partitioned. These systems must communicate to coordinate memory and disk access and to exchange data. This typically requires that shared SCSI disks be used in addition to a LAN-style interconnection. The next version of Microsoft Cluster Server Wolfpack Phase 2 will attempt to provide this capability. 445

SERVER INFRASTRUCTURE Concurrent Access Clustering Concurrent access clustering uses a very-high-speed interconnect to enable multiple instances of a service application to function as a single entity, operating against a single data set. This enables dynamic load balancing and dynamic user distribution in case of a node failure. Adding a machine to the cluster results in a near-linear increase in performance, provided that the interconnect and disk-sharing systems are fast enough to support it, which in turn provides a high level of scalability. This technology, which first appeared in Digital’s VAXcluster over 10 years ago and exists in the midrange market, has not yet reached the PC server market. THIN-CLIENT SUPPORT The microcomputer industry has always worked from the assumption that putting more computing power on users’ desks will empower them to become more productive. Unfortunately, the race to build more and more powerful clients has also meant that a greater percentage of an organization’s computing power is not in the clean, controlled environment of the glass house but out at the users’ desks where it is difficult and expensive to maintain. This problem came to a head in the past two years when The Gartner Group received a huge amount of press covering their Total Cost of Ownership (TCO) analysis that showed the cost of supporting a desktop PC in a typical organization exceeded three times its purchase price. In response, vendors have developed a class of devices that provides a graphical user interface allowing users to run the kind of office automation applications that they have become accustomed to, while reducing the amount of maintenance required. These “thin clients” range from X-Terminals and Windows Terminals, both of which shift most or all of the computing load to the server, to Java-based Network Computers (NCs) and NETPCs, which are more powerful computers in their own right. While these technologies have been discussed at great length in the press, they have yet to find acceptance in the lucrative corporate market. FC-AL Fibre Channel-Arbitrated Loop (FC-AL) is a subset of Fibre Channel technology. Using FC-AL, the storage subsystem delivers higher performance and is more cost efficient and more failure resistant than a storage subsystem implemented with parallel SCSI technology. There are numerous benefits of FC-AL:

446

Server Issues and Trends, 2000 • delivery transfer rates of up to 100MB/sec in each direction between nodes • support of up to 126 devices • support of SCSI protocol so most I/O drivers need only minor changes • highly sophisticated error-detection scheme In a relatively low-cost manner, Fibre Channel can yield considerable benefits for users of storage subsystems: higher availability, higher scalability, higher performance, and very high capacity. These features are becoming crucial as companies increasingly rely on swift and continuous access to large volumes of data to support line-of-business applications. SUMMARY All these trends put together means that there will be faster, smaller, more efficient, cheaper, easier-to-manage servers next year — just like this year we had them relative to last year. After all, if the automobile industry was like the computer industry, a Rolls Royce would have a top speed of 700 miles an hour, get 600 miles to the gallon, and cost 23 cents. The differences between Intel servers is shrinking. Five or six years ago the super server products were very different from each other and from a Compaq server and other standard PC boxes running NOSs. Today, those differences are smaller. An AST server based on Intel’s SHV motherboard is very similar to an HP or Compaq server. Over the next couple of years, it will be very difficult to come up with true technical differentiation.

447

Chapter 37

Web Site Design and Performance for Intranets Ralph L. Kliem

COMPANIES ARE QUICKLY SEEING THE ADVANTAGES OF PURSUING INTRANET applications, and the predominant reasons are increasing productivity and communications. The Business Research Group found that 75 percent of companies want to set up an intranet to increase effectiveness, and another 52 percent to save on communications costs.1 However, realizing these advantages of the intranet does not come easily. Logic dictates that the first step in increasing effectiveness and improving communications is to create Web pages that will do the job — but yet the evidence seems to the contrary. Many Web pages share a lot of characteristics of earlier interfaces and the content of immature mainframe and client/server systems, thereby defeating effective communications and productivity. Here are a few examples: • • • • • • • • • • •

a feeling of “Oh my gosh, where am I going?” after selecting an icon cluttered screens, especially with graphics cryptic messages excessive navigation and hypertext links large blocks of text long processing speeds poor grammar and spelling too many frames too many and too large icons and graphics too much audio or animation unsparing use of color

There is more. Many organizations release sites that are incomplete (e.g., the construction worker shoveling is a popular indicator of an incomplete site). Others release untested or poorly tested sites, exemplified by 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

449

SERVER INFRASTRUCTURE visitors finding themselves lost in a tangled web of links. Still others release sites with errors either in the content or with the links. The impacts are real. Visitors no longer bother to visit the site because they find the design frustrating. The Web pages are no longer a valuable communications tool once the reliability and integrity of the information comes into question. In the end, the servers become burial grounds for unvisited Web sites. REASONS There are four major reasons for why many Web sites that exist are ineffective and inefficient. 1. More is better. Put as much as possible on a Web page. ‘More’ might be text or graphics, or both. Never mind the relevancy, just put everything remotely related to the subject on the Web page. “Keep them full” and visitors will never leave. After all, goes the reasoning, why not put ten pounds of groceries in a five-pound bag if one can do it? 2. Plenty of glitter. Many Web sites, thanks now to Java, are putting more glitter than substance on their pages, such as movable or flashing icons and graphics, for no other purpose than to draw attention. Yet, trying to find something simple like an address to contact someone is like walking blindfolded through a maze. Glitter like this raises the question, “Wow, but what is the message?” 3. Excessive linkage. Many sites add links to other sites which, in turn, provide navigational and hypertext links to other sites. After awhile, the linkage gets so elaborate the visitor gets lost. The linkage turns into a chaotic sailing escapade similar to Minnow in Gilligan’s Island getting lost in a storm and the crew never having any idea where they are or how to return from where they came. 4. Get it out there first. It seems that everyone wants to have the first Web site, or at least be one of the first. By being in the forefront, recognition comes right away. Forget about the interface or content design of the Web pages. Just get that Web site up and running, even at the risk of sacrificing quality and the organization’s image. BACK TO BASICS The four reasons given above contribute to poor Web site design, indicating that designers failed to answer the following fundamental questions before writing the first line of HTML. • Who is the customer? Who does one want to access the site? • What is one trying to communicate to the customer? Is it to persuade them to action? To provide them data? • Why should they visit your site as opposed to another site? 450

Web Site Design and Performance for Intranets • Where can the customer go to get access to the site (e.g., through a search engine)? • When should one modify or update the site? Frequently? Never? • How is one going to get customers to visit? How is one going to lure them to the site? A good approach to building a Web page is to borrow a technique used by designers of the past for earlier technologies: build a model of what the site should look like using a paper prototype. As in the past, a prototype can go a long way in helping to answer the six fundamental questions above. Another excellent approach that has worked in the past is to hold a beta test. Select people who are not knowledgeable about Web design and have them access and navigate through the new Web pages. Record their insights, especially about the “look and feel,” and then make any appropriate changes. Of course, good Web design not only just makes Web site visitations a pleasure, there are also other advantages. For one, it helps to reduce or slow down the increasing need for bandwidth and storage requirements. It also makes content maintenance and path management easier because there is less to track. A superb book that people can still learn from and is just as relevant today as it was 15 years ago is Paul Heckel’s The Elements of Friendly Software Design (Warner Books). The principles described in the book, if applied to Web sites, would go a long way toward improving design and content of many internal sites. The emphasis in the book is on the user’s intuition and perspective — and not on his ability to unravel complexity. In other words, it calls for designing systems from the “outside in” and not from the “inside out.” REMEDIES Naturally, bad design weeds out the good, and the potential for getting worse increases with each Web site going online. Here are some tips to ensure that Web sites in the future do not encourage bad design. • • • • • • • • • •

apply simplicity in word and image choice ensure clarity of message ensure contents and paths are active and relevant have text and graphics support one another keep consistent in layout and terminology logically structure content minimize excessive navigation modularize layout prefer the specific to the general provide ease of access to data or information 451

SERVER INFRASTRUCTURE • • • • • • • •

provide straightforward navigation within the site spell correctly standardize page layout use proper grammar use graphics, video, and color selectively to emphasize a point use meaningful messages and ease of recovery when an error arises use plenty of white space to reduce clutter and increase readability use a positive tone throughout all pages

Here also are some tips to improve intranet efficiency that will increase bandwidth and reduce download speed. • give visitors choices whether to download hypermedia like audio, video, and plug-in files • prepare a Web usage policy to control surfing during key production hours • provide a site map, accessible directly from the home page • provide options for viewing text only • restrict graphics to 30,000 bytes or less • set up standards for Web site design (e.g., common structure and organization) • store icons in GIF rather than JPEG format • use capacity planning and performance management tools and techniques to track and monitor bandwidth requirements • use frames sparingly • use Java applets only when necessary • use thumbs and interlaced GIFs for larger images When developing a Web site, also consider the network infrastructure that supports the site by answering questions like, does the network: • minimize response and queues through load balancing or other performance management approaches? • provide data on network performance and use that data to continuously optimize and configure the network? • support different operating systems and servers? • support existing and growing number of users on the network in general and the number of visitors to a site in particular? On a client level, there are hardware options to improve performance on the client side. Two common improvements are increasing the amount of random access memory (RAM) and installing faster CPUs and controller cards. On a companywide level, the options include increasing the number of servers, making more powerful servers available during peak periods, and providing higher speed lines to the servers. 452

Web Site Design and Performance for Intranets On the same level, it makes good sense to put together something like a standards and guidelines manual for building Web pages. The manual might provide a recommended page layout; templates of different layouts of Web pages; guidelines for use of graphics, audio, and animation; instructions for dealing with copyright issues; maintenance of content and links; and how to handle errors and other difficult situations. The manual could go a long way in “weeding out” the bad and encouraging the good in Web page design. IT IS UP AND RUNNING. NOW WHAT? Having new Web pages up and running is only half the battle. The other half is maintaining the site. One way to maintain a site is to conduct periodic reviews. These reviews should focus on the “staleness” of the content, its relevancy, and its appearance. Although the content may be current, visitors may grow tired of the appearance and cease visiting. Navigational maps (for detecting nonexistent links and seeing how all the links and pages relate to one another) and storyboards can ease the maintenance of Web pages. However, there is more that one can do. On a solo basis, Web site maintenance is relatively easy. Some activities include monitoring to ensure that: 1. 2. 3. 4.

content is accurate and current functionality and transactions are reliable links are active site accessibility is provided to all current browsers and hardware configurations

As the number and purposes of Web sites grow, however, management tools can play a very important role in site maintenance and management. These tools allow tracking and analyzing traffic to, from, and within a Web site. They also allow fine-tuning of one or more Web sites and, indeed, an entire network, if necessary. For an individual site, a log tool collects information about access to a site via log files residing on a server. Typically, this file will provide a plethora of data on visitors to a site, such as IP address, date and time of access, pages visited, and any downloads. It also tracks any errors that users may encounter when accessing the site. The volume of data can become quite large, of course, so content analyzer software can prove quite useful. A content analyzer tool can compile the data and convert it into information to answer questions like: • What are the statistics for the average number of visitors per day? What are the most and least active days? What is the most and least popular browser used? 453

SERVER INFRASTRUCTURE • What broken links exist? • What are the most common errors that visitors experience? What is the source of those errors? • What is the most frequent activity at the Web site (e.g., surfing or downloading)? • What is the number of visitors to the site? • What are the best, least, and average response times? • What links lead visitors to the site? • Which Web pages and files are the most popular during different time intervals? Answers to the above questions can help fine-tune and maintain the Web site by eliminating or reducing the least frequently visited Web pages, shifting files to more frequently visited Web pages, developing more appealing content, and fixing problems that lead to errors. A number of log file analysis tools exist on the market that provide either reporting or error corrections, or both. A graphical reporting capability is especially useful to track and monitor site visits over a period of time. On a grander scale are Web-based performance management tools for a server or an entire network. These tools not only collect data about specific sites but also on an array of servers to track and monitor the performance of servers and networks. They can help provide data on individual sites but also the overall performance of the entire network. These tools specifically enable one to: • perform an analysis of traffic (e.g., most frequently visited sites and most active paths) • create and maintain individual sites (e.g., identify broken links and slow downloading files) • detect server failures and provide adequate recovery procedures • develop a more effective accounting practice for use of the servers • develop a more efficient allocation of bandwidth scheme • develop a more optimized configuration using load balancing techniques • filter access to certain files • identify “spikes” in bandwidth usage that cause traffic bottlenecks • identify event sequences • identify the most frequent problems dealing with the connections with communications devices (e.g., modems, routers) • manage bandwidth requirements and project future needs (e.g., during peak periods and simulating traffic) • map existing server configurations • provide “alerts” of existing or impending problems with the network • provide site update and replication services (e.g., for remote Web sites) • track server availability 454

Web Site Design and Performance for Intranets ONLY GOLD GLITTERS If one likes to use the comparison of a Web page to a page in a book, then it is especially clear that few people are studying the past. The layout of a Web page is very much like the page of a book. The best practice, therefore, is to capitalize on what has worked best in the past to make the transition easier. It is amazing how even the fundamental questions get overlooked by the glitter of Web technology. Yet, answering and applying the fundamental questions can go a long way toward turning a site into an effective communications tool rather than just an electronic brochure that people toss after the first reading. Notes 1. Surfing Down the Cost Curve, CommuicationsWeek, July 22, 1996, p. 12.

455

Chapter 38

Linux and the Web Srinivas Padmanabharao

A REAL THREAT TO MICROSOFT’S DOMINANCE OF THE DESKTOP OPERATING system workspace could come from the creation by a Finnish student Linus Torvalds in the form of a freely available operating system — Linux. Linux was originally developed by Linus and then enhanced, debugged, and completely rewritten by thousands of programmers around the world, and today poses a credible threat to the domination of Microsoft. While Linux is still a few years away from appearing on every desktop around the world, its use as a server operating system has shown a remarkable increase over the past year. International Data Corporation (IDC) estimates that shipments of Linux for use on servers rose by about 212 percent in 1998, capturing about 17.2 percent of the market compared to 35.8 percent for Windows NT. This chapter presents a look at the world of Linux. LINUX: THE OPERATING SYSTEM Linux is a UNIX-clone operating system. It is a freely available implementation of the published POSIX standards and does not use any of the UNIX source code. Linux traces its roots to another free operating system for the x86 architecture called MINIX, developed by Andy Tanenbaum. Linus Torvalds, inspired by the desire to create a better MINIX, took this code-base, modified the kernel, added a driver for keyboard and screens, and released it as Linux under the General Public License (GPL) in 1991. Since then, thousands of users have contributed to and enhanced the basic Linux kernel and code. In essence, Linux is just a kernel and needs to be packaged with lots of applications, drivers, and tools to make it into a complete usable operating system. However, Linux is commonly used to refer to the kernel along with all other pieces of software needed to make the kernel useful. Obtaining Linux The two most common ways of obtaining Linux are: • By FTP over the Internet. Linux is usable under the General Public License (GPL). This means that Linux is available, free of charge, in 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

457

SERVER INFRASTRUCTURE both binary and source code forms and can be used without the need for any agreements, etc. by as many users as a system will support. There are many mirror sites over the Internet from where one can download Linux,1 and choosing the nearest site is usually better. First-time users are better off downloading a stable version of the system; a version x.y.z, where y is an even number (including zero), is a stable version. • Through a commercial distribution. Although Linux is itself free, one is allowed to charge a fee for packaging it into an easy-to-install product usually referred to as a distribution. Such distributions come with all the other associated software needed to make it useful, that is, desktop interfaces, network management tools, etc., and documentation. They are made available via CD-ROM. Examples of such companies are RedHat (Version 5.1 costs U.S.$49.95), Caldera, and Slackware. It must be remembered, however, that all software found on the CD-ROM can also be obtained free over the Internet, and it might be a worthwhile exercise to go through, for the adventurous types. Hardware Requirements If one has purchased a PC anytime during the last five years, one probably already has a machine that is ready for Linux. (Of course, if one has not, then it is probably time to call the nearest museum and claim possession of an antique relic.) While Linux was initially written for the PC, versions are available for other bigger machines. IBM is porting Linux to its RS6000 machines — if one needs proof of its growing popularity. Linux supports Intel processors 386 and higher along with their clones. It also supports many DEC Alphas, Sun Sparcs, and Power PCs to varying extents. On the memory side, Linux will function reasonably on anything greater than 8MB of RAM. However, if one is using the X-windowing system and planning to use a lot of programs, then a single user system will perform satisfactorily with 32MB of RAM. One might want to consider adding more memory, around 8 to 16MB per additional user of the system. Linux can support upto 1GB of RAM. The falling price of storage makes it affordable and sensible to have at least about 4GB of hard disk space, although the base Linux kernel can be installed in less than 15MB. Drivers for most types of peripherals (e.g., a mouse and sound card, video card, network card, and modems) can be found. Most distribution vendors maintain a more complete and updated list of supported hardware. If a driver cannot be found for a very special piece of hardware, one is welcome to write one and contribute to the Linux effort. 458

Linux and the Web Installing Linux Linux has come a long way from the days when it was a hacker’s operating system. If installing Linux off a commercial distribution, then one will also usually get installation support for the price one has paid. Documentation is also available, along with the distribution. If installing Linux off the downloaded code from the Net, then one can also get a guide on installation from the same site. Linux HOWTO documentation is a good source.2 Instead of going into the gory details of a screen-by-screen description (i.e., a command-by-command description), emphasis is placed on the need for planning for the installation. Answer at least the following questions satisfactorily before jumping ahead. 1. What are hardware specifications on the machine? Get all the details of the hardware on the system. This will allow for installation of the needed drivers and prevent many a headache later. 2. What is this system going to be used for? If installing Linux on a machine at home with the intention of using it for personal pursuits, then one might want to make sure to also install the Xfree86, which provides a graphical user interface. If one intends to use it as a Web server, ensure that there is enough space to hold the Web server software (e.g., Apache), enough space for all the Web pages one will host, and enough space for any HTML editors one wishes to use. 3. Does one want to use two operating systems? It is not unlikely, especially if the system is at home, that one will want to retain the other operating system that is already present (like MS-DOS or some flavor of the Windows family). In that case, one might want to provide for the option of a prompt, i.e., Linux will ask you which system you wish to use at bootup time. Of course, one can access other files from the Linux environment by mounting it appropriately. Some Features of Linux Having gone through the installation ordeal successfully, rest assured of having become the owner of a system that runs one of the best operating systems available. Here are a few of the features of the operating system. • Multitasking and multi-user. Like any UNIX system, Linux supports many users, each running many programs simultaneously. Linux also supports virtual consoles; this feature allows one to have multiple sessions and log-in as two users simultaneously (use ALT-F1 to switch between sessions). Use the feature judiciously — determining one’s current status can get pretty confusing, which is why one has commands like whoami. • Multithreading. Linux has native kernel support for multiple independent threads of control within a single process memory space. It runs in protected mode on the 386, implementing memory protection between processes, so that one program cannot bring down the entire system. 459

SERVER INFRASTRUCTURE • Memory management. Linux demand loads executables; that is, it reads only those parts of a program that are actually used. Linux increases speed by using shared copy-on-write pages among executables. This means that multiple processes can use the same memory for execution. When one tries to write to that memory, that page is copied somewhere else. Linux uses a unified memory pool for user programs and disk cache, so that all free memory can be used for caching, and the cache can be reduced when running large programs. • Multiple file systems. Linux supports several common file systems, including Minix, Xenix, and all the common system V file systems, and has an advanced file system of its own, which offers file systems of up to 4TB, and names up to 255 characters in length. It provides transparent access to MS-DOS partitions (or OS/2 FAT partitions) via a special file system. VFAT (Windows NT, Windows 95) support and FAT-32 is available in Linux 2.0. A special file system called UMSDOS is also available; it allows Linux to be installed on a DOS file system. Linux supports a CD-ROM file system that reads all standard formats of CD-ROMs. • Compatibility. Linux is compatible with UNIX, and most applications that have been written for UNIX can be recompiled to run on Linux with little or no modification. Linux is highly interoperable and can coexist in a diverse environment with Netware and Windows NT. • Networking support. Linux supports TCP/IP networking, including FTP, telnet, etc., that makes it ideal for use on a Web server. A comparison of Linux with most of today’s popular operating systems can be found on the Web3; this can be used to compare the performance of Linux with other operating systems. LINUX APPLICATIONS An operating system by itself provides very limited functionality for end use. It is the applications like databases, word processors, and development tools that determine the ultimate success of any operating system. It is in this respect that Linux has had an amazing success story. Because the Linux source code is freely available, it has provided developers around the world with the freedom to develop applications for this operating system without the need for acquiring expensive licences from any vendor. This freedom has led to the development and free availability of a wide variety of software applications, such as: • development tools, including compilers, assemblers, and debuggers • text editors and word processing software • a whole host of Internet applications, such as usenet news readers, and e-mail agents • World Wide Web development tools, Web servers, and browsers • graphics creation and manipulation tools • databases 460

Linux and the Web A complete list of all applications available is maintained under the Linux Software Map (LSM).4 The Linux Documentation project5 is an excellent source of documentation for all Linux-related material, including applications for Linux. ENABLING E-COMMERCE In the Internet-crazy times of today, one of the key objectives of any company is to prepare itself for E-commerce. Today, companies are moving beyond the realm of providing static information on their Web sites and actively enhancing their Web sites to provide opportunities for interaction with the customer. In this context, the key enabling technologies that a company must consider include: • a database to store information • a Web server software to present a front end to the world • a tool to connect between the two and provide a mechanism for actively updating the database with customer details or provide customer-requested information Keeping with the spirit of freedom in Linux, this chapter reviews the Apache Web Server, which runs on over half the servers on the Internet; a database called PostgreSQL; and an interconnection tool called PHP. PostgreSQL PostgreSQL originated from a research project in Professor Michael Stonebraker’s group at Berkeley. It is a high-performance, robust object relational DBMS. It provides a full-featured API for development of client/server or n-tier applications. Also, via PHP/FI, it can be easily integrated with any Web site as a high-performance back end. PostgreSQL is freely available under the GNU public license, and a copy of the PostgreSQL database can be obtained from its Web site (http://www.postgresql.com)/. Key Features. Key features of the PostgreSQL database include:

• • • • • • •

Web/Apache interface graphical interface APIs: C, C++, TLC, Perl, Python, and Java ODBC JDBC online backup regression testing package included to ensure reliability

PHP PHP is a server-side, cross-platform, HTML-embedded scripting language. Rasmus Lerdorf conceived PHP sometime in the fall of 1994. It was 461

SERVER INFRASTRUCTURE initially known as Personal Home Page Tools. PHP Version 3.0 is an HTMLembedded scripting language. Much of its syntax is borrowed from C, Java, and Perl — with a couple of unique PHP-specific features thrown in. The goal of the language is to allow Web developers to write dynamically generated pages quickly. PHP can be obtained free of charge from its Web site (http://www.php.net). Key Features. Key features of the PHP interconnection tool include:

• HTTP authentication; HTTP authentication is available only when PHP is running as a module in the Apache server • GIF creation • file upload support • HTTP cookie support • database support; this is probably the most powerful feature of PHP, with its ability to connect to both commercial databases (e.g., Oracle and Informix) and free databases (e.g., PostgreSQL) • regular expressions for complex string manipulation • error handling • connection handling • PHP source viewer Apache Web Server One of the key pieces of software needed on a Web server is the HyperText Transfer Protocol (HTTP) server. When an end user enters a URL in order to view the Web site at the server end, it is this HTTP server that processes the request and sends the required information back for formatting and display by the browser. One can download Apache free of charge from its Web site (http://www.apache.org). Key Features. Key features of the Apache Web Server include:

• • • • • • •

• • • • 462

a powerful, flexible, HTTP/1.1-compliant Web server implements the latest protocols, including HTTP/1.1 (RFC2068) is highly configurable and extensible with third-party modules can be customized by writing modules using the Apache module API provides full source code and comes with an unrestrictive license runs on most versions of UNIX without modification DBM databases for authentication; it allows one to easily set up password-protected pages with enormous numbers of authorized users, without bogging down the server customized responses to errors and problems allows multiple DirectoryIndex directives unlimited numbers of alias and redirect directives content negotiation

Linux and the Web • multi-homed servers facility, which allows the server to distinguish between requests made to different IP addresses (mapped to the same machine) CONCLUSION The world of Linux and its applications offer great promise to developers and IT managers alike. Following the open source model of development, a number of diverse and reliable applications have been written and are available free of charge. Picking and choosing between them can enable today’s IT manager to provide his company’s presence on the Internet in an easy, quick, and cost-efficient manner. These offer even greater promise to those small businesses that are cash strapped. ACKNOWLEDGMENTS The author is thankful to all supporters of the Open Source concept and those who are involved in developing such wonderful applications. My friend Sanjay Verma has been very helpful in this endeavor. Notes 1. 2. 3. 4. 5.

ftp://sunsite.unc.edu/pub/linux. http://metalab.unc.edu/LDP/HOWTO/Installation-HOWTO.html. http://www.falconweb.com/~linuxrx/WS_Linux/OS_comparison.html. http://www.execpc.com/lsm/. http://metalab.unc.edu/LDP/.

463

Chapter 39

Web-to-Host with VM/ESA: A Viable Platform for the Internet Jim Foxworthy

THE

RAPID - FIRE PACE OF TECHNOLOGY IS CHALLENGING US

—

AND

changing how business operations are managed. Take the World Wide Web as an example. The days of providing Web sites that only offer brochureware are gone. Acceptance of the Internet, intranets, and extranets has now been replaced by expectation. Today, expectations of a Web interface include detailed exchange of business-critical information. Customers, employees, and business partners expect to seamlessly extract information from various platforms and use it on their desktops. This problem is complicated by the latest revolution: E-commerce. Not only do E-commerce systems use new technologies, but these systems are also directly tied to the bottom line. Organizations are turning to the Web to allow them to streamline their businesses in order to maintain a competitive advantage. Before E-commerce can become mainstream, it will be necessary to satisfy another set of business requirements — providing continuous availability, peak performance, robust security, and high reliability. Thus, IT management is faced with a true conundrum: how to combine the flexibility and ease of use seen in desktop systems linked to the Internet with the system characteristics of RAS — reliability, availability, and scalability. This dynamic puts pressure on IT. Nearly 30 years of application development resides on legacy systems that were not designed for the Internet. What must be done to these systems so they will meet user expectations and leverage the existing investment? 465

SERVER INFRASTRUCTURE

APPLICATION PROFILE Content

Text images

<10

Text forms

Text, data, graphics, audio

Text, data, large graphic & image files audio/video

Text, data, graphics

Large text & data files, graphics, images

250

300

500

1,000

1,200

1,625.8 1.4 22.8

7,429.8 0.6 44.6

7,676.7 1.1 84.4

8,304.3 0.8 66.4

7,426.6 1.4 104.0

NT (2 CPUs) 67.5

UNIX (2 CPUs) 123.1

UNIX (2 CPUs) 127.3

UNIX (2 CPUs) 134.7

MAINFRAME CONFIGURATION Total Cost ($000) Peak Used Capacity (%) Web Server Costs ($000)

3,260.9 0.3 9.8

ALTERNATIVE SERVERS Server Type Web Server Cost ($000)

Exhibit 39-1.

NT (1 CPU) 62.8

NT (1 CPU) 64.3

Platform cost comparison (source: International Technology Group).

One misconception that quickly comes to mind is system migration. The supposition is that legacy systems should be moved to alternative platforms, because those platforms have characteristics designed for Internet applications, in order for desktop systems to connect to them. However, legacy systems can, in fact, connect directly into the Internet via the desktop. Many of the alternative platforms are also still evolving and, unlike the mainframe, deliver only minimal levels of RAS. Even those platforms that have achieved acceptable levels of RAS still lack robust systems management tools, creating high levels of total cost of ownership (TCO). See Exhibit 39-1. According to the International Technology Group in Mountain View, CA, not only does the mainframe have the ability to support a high number of hits per minute, but it also has the lowest Web server cost compared to the NT and UNIX alternative servers. Every mainframe application represents a significant investment that should not be casually discarded. One alternative to migration is putting a new front end on the application. This allows for easy extension of its life, freeing one to focus resources on developing new applications for the organization. And there is a light at the end of the tunnel. A solution is available today that allows one to provide access to legacy applications directly from a desktop system while those applications are stored on a platform that delivers high levels of RAS. This chapter discusses the merits of bringing mainframe applications to the Web browser using the IBM VM/ESA operating system as the platform for the Web server.

466

Web-to-Host with VM/ESA: A Viable Platform for the Internet VM/ESA: A PLATFORM FOR THE INTERNET Over the past 25 years, VM/ESA has established itself as a premier mainframe platform for server applications on small and intermediate S/390 servers. Customers of VM/ESA have extraordinary loyalty to this platform, in large part because of its proven capabilities for application development and network computing. Many organizations continue to rely on VM/ESA to manage their vital applications — including order-entry system, finance, accounting, payroll, etc. Although still reeling from the “politically incorrect” days of the early 1990s (before the merits of the Web were fully realized), use of VM/ESA as a Web server has become more popular as Web commerce applications become more prevalent. As organizations tie their day-to-day processes and applications to the Web, the mainframe is becoming a more logical platform due to its proven delivery of RAS. The mainframe is a natural for Ecommerce because that is where the data typically resides — about 70 percent of corporate data according to the Meta Group. The Yankee Group, an industry analyst firm, believes that two factors are driving the demand for mainframe-based Web server applications among mainframe users. First, the Web is increasingly used as the business transaction medium. If businesses are to depend on the Web, then their Web server must be able to meet all the demands that come from that dependency. VM/ESA has a proven history that has shown it can deliver reliable results. Second, mainframes provide the most scalable and secure transaction processing environments. Web server applications placed on alternative platforms tend to quickly outgrow those platforms. The Yankee Group expects to see this expansion continue, which will create a significant demand within organizations for processing power, storage, and robust connectivity solutions. VM/ESA offers extraordinary flexibility in these areas. Frequently implemented on mainframes as a hypervisor, or master operating system, VM/ESA has local access to multiple guest operating systems and their applications. As a Web server, VM/ESA can act as a gateway to all the established legacy systems in an environment without creating new connections between systems, and without the addition of a new platform. VM/ESA is well-positioned to be a key component of an organization’s World Wide Web strategy. With VM/ESA, organizations can exploit Web technology to regain control and management of information, using existing infrastructure and current investments in hardware, software, and personnel skills.

467

SERVER INFRASTRUCTURE Part of the reason VM/ESA appeals to organizations is due to its reliability, availability, and scalability, which are still considerably ahead of alternative platforms such as UNIX and NT. In one sense, Web serving on VM/ESA is simply the latest example of successfully capitalizing on these traditional strengths. Today, keeping pace with the growing number of clients running graphical Web browsers and the increasing volume of transactions occurring over the Internet requires more powerful Web servers. In addition to taking advantage of highly scalable S/390 platforms, native VM/ESA Web servers also enable one to serve existing mainframe data to a new generation of interactive graphical applications. A summary of the key advantages of VM/ESA as a Web server platform follows. 1. Easy to add a Web server to VM/ESA: a. VM/ESA supports TCP/IP b. VM/ESA stores all data types c. A Web server is simply a service virtual machine 2. VM/ESA excels at handling volatile workloads 3. VM offers unmatched quality and RAS 4. VM/ESA is a mainframe system: a. powerful and scalable b. storage capacity, bandwidth, redundancy 5. VM/ESA is extremely cost-effective: a. ever-decreasing costs per user and transaction b. lowest administration costs of any platform GOOD NEWS/BAD NEWS Although legacy applications continue to offer reliability and high performance, they also present two obstacles to users: • Restricted access. To use mainframe applications, users must connect to them through 3270 terminals or PCs running 3270 emulators. Users want access to information not just from the office, but also from home and on the road. • Antiquated interface. Users find the text-only 3270 interfaces of mainframe applications antiquated and difficult to use. Today, users rely on a desktop or laptop system and demand graphical user interfaces (GUIs), preferably provided through the same Web browser used to navigate the organization’s intranet. These obstacles represent the greatest drawback to E-commerce applications over the Web. The application logic, and the data locked away in legacy systems, represent one of an organization’s greatest assets. And the mainframe represents a viable option to host a Web server. If a solution 468

Web-to-Host with VM/ESA: A Viable Platform for the Internet

LEGACY APPLICATION 3270 Uuser Interface

Application

$

Exhibit 39-2.

Database

$

Legacy investment: locked away from the desktop.

could be crafted to improve the access from the Web to legacy assets, then the VM/ESA platform would represent a complete solution for E-commerce applications. UNLOCK THE POWER OF YOUR MAINFRAME APPLICATIONS So, how can organizations meet their users’ needs for a graphical interface without the costs and risks of replacing proven mainframe applications? The answer lies in both Web-enabling (providing Web browser access to an application) and Web-enhancing (exploiting browser capabilities to improve user interface) these applications. By putting a graphical Web browser front end on mainframe applications, organizations can extend these applications and data to a wider audience in an easier-to-use format. This allows organizations to get additional returns on their VM/ESA investment (see Exhibit 39-2). Web-enablement represents the fastest and least-expensive solution. By use of a utility program, the 3270 data stream produced by legacy applications can be programmatically converted to HTML format. While the appearance of the screens is still antiquated, operations previously performed with PF keys are now done through button-clicks and scrolling bars. A legacy application with several hundred screens can be Web-enabled by a single person in a matter of minutes. Web-enhancement represents a solution that leverages the power in the desktop graphical user interface. Through the use of programming tools like CGI scripts, application programmers can quickly and simply create new screen displays that are more intuitive and more closely match the expectations of end users. Icons, point-and-click, hyperlinks, etc. can be added to the GUI; thus, it becomes irrelevant from the user’s perspective where the data is housed. 469

SERVER INFRASTRUCTURE Web-enhancement of a legacy application with several hundred screens can be approached in multiple ways. First, the entire application can be initially Web-enabled; then, only those screens most critical or most often used can be Web-enhanced. A single person in a matter of days can complete this process. Second, one may choose to Web-enhance every screen in the application, which can take a few weeks. CASE STUDY — LAFAYETTE LIFE: A MAINFRAME-BASED APPROACH TO THE WEB The insurance industry, like other industries, faces an increasingly challenging environment. In life insurance, deregulation, mergers and acquisitions, and competition from banks are obliging companies to adopt new strategies. Customer demands for greater convenience are driving growth in call centers and online services. As other channels expand, the role of agents is changing. One of the top ten U.S. life insurers, Lafayette Life, has diversified into a broad range of financial and insurance planning services, and has pursued an aggressive growth strategy resulting in average annual growth of more than 8 percent in premium income since the early 1980s. At the same time, the company has consistently maintained high ratings for asset quality, and has contained administrative overhead through a policy of rigorous cost control. Management believes that the Internet will play an increasingly important role in the company’s business. A range of potential benefits has been identified, including reduced administrative and telecommunications costs, faster product development and delivery, improved customer service, and increased support for agents. Challenges In 1997, the company decided to offer Internet access to its group life insurance customers as well as to its more than 1000 agents throughout the United States. The ideal solution, management believed, would be to adapt its New Online Administrative System (NOLAS). NOLAS is a mainframe-based custom system developed in the early 1990s that handles all key business processes. Accounting for more than 90 percent of the company’s transactional and decision support workloads, NOLAS integrates all functions from policy issue to claims processing, and employs a common relational database for all customer, policy, and claims information. The system had played a major role in the company’s success in the past, and its functionality was a good match with requirements for conducting business via the Internet. It has been easily adapted for internal and extranet users by deploying a VM-based Web server. 470

Web-to-Host with VM/ESA: A Viable Platform for the Internet Solution The company’s IT organization reviewed several options. It became clear at an early stage that there was no need to develop new applications. NOLAS had proved highly effective, and it made more sense to leverage the system’s competitive strengths via the Internet than to incur the costs and delays of building a new solution. Use of a host access gateway running on a UNIX or NT server was also rejected. This was partly because of the poor quality of the interface, and partly because — as management put it — this approach would “add one more layer of complexity.” Because data and application logic were already mainframe based, the fastest and most cost-effective solution was to add a Web server to the VM system. A pilot system was brought into operation in less than six weeks. The pilot began in January 1998, and full NOLAS operations via the Web were realized by December 1998. In contrast, development of new applications would have taken twice as long, and would have required at least three to five times more developer time. Benefits Early experiences have been highly positive. By enabling group customers to input new policy data and changes electronically rather than sending paper forms, administrative costs have been reduced, and problems caused by misspellings, illegible handwriting, and other errors have been removed. Because delays caused by mailing and processing of forms have been eliminated, coverage now begins almost immediately, and customers no longer pay premiums for extra days or weeks after employees have left. For corporate customers with large numbers of insured employees, this adds up to substantial savings (see Exhibit 39-3). Agents also experience faster, easier access to up-to-date information, and the company is able to reduce its own administrative costs by eliminating manual data entry. An additional benefit is that browsers provide more user-friendly access to NOLAS, which had been originally designed with a character-based interface. “Revamping our old 3270 applications eliminated cumbersome log-on procedures, cryptic function keys and messages, and cluttered display screen,” says Bob Nix, Technical Support for Lafayette Life. This approach has, again, proved faster, simpler, and less expensive than more complex techniques for delivering GUI capability. NOLAS is being extended to the Internet and intranet with essentially no changes to existing application code and data. 471

SERVER INFRASTRUCTURE

Exhibit 39-3. Lafayette Life mainframe-based system.

The mainframe-based approach also benefits from the high levels of availability provided by this system. The company is able to provide almost continuous 24-hour-a-day, 7-day-a-week (24 7) access to customers and agents who are spread across three time zones, and many of whom work outside normal office hours. The system is taken offline for only 30 minutes each month for scheduled maintenance tasks. The Internet is an important new channel for insurance companies. But management believes that competitive success or failure will continue to be determined by quality of products, responsiveness of customer service, and financial discipline. Most of the technological options reviewed by the company would have added complexity, cost, and delay for solutions that provided no functional advantage, and did not contribute in any way to the realization of the company’s core business goals. Using VM made better business sense. Here are some tips to consider when bringing mainframe applications to the Web. It should be noted that VM-based Web-to-host solutions typically meet the criteria in Exhibit 39-4. CONCLUSION With VM/ESA, organizations can cost-effectively make mainframe-based business information more accessible and easier to use. VM/ESA cost of operating is less expensive per user than any other computing platform due to low storage and overall total costs. Studies by consulting organizations such as the International Technology Group show that per-user costs of PC/LAN environments are typically three to four times greater than peruser costs of mainframe systems such as VM/ESA. VM/ESA total cost of ownership is low because it has low administration costs and a robust set 472

Web-to-Host with VM/ESA: A Viable Platform for the Internet

Exhibit 39-4.

Checklist for Selection of Web-to-Host Solutions.

1. Retain both data and applications on the mainframe and use Web technology to improve accessibility and usability. This allows one to maintain extensive mainframe investment, while simultaneously addressing user needs for more friendly interfaces and universal access to information. 2. Maintain only one copy of information on a system that is accessible to any authorized user with a Web browser. Changes to information and business rules are instantly available to everyone, so an entire organization is kept up-to-date with minimal effort. 3. Address applications on all mainframe platforms and handle full-screen applications — without rewriting the applications. The reason for beginning this effort in the first place was to avoid the risk of migrating to another platform and having a negative impact on the availability or performance of business-critical applications. Unlike VM, typical mainframe Web servers cannot address full-screen applications unless one modifies the applications. 4. Provide both a Web-enabling as well as a Web-enhancing tool that offers complete flexibility to customize interfaces. It is imperative to avoid being locked into a solution that only “Web-enables” applications and retains the old 3270 look and feel. Today, end users demand that their applications have intuitive graphical interfaces. 5. Scale the Web solution enterprisewide without requiring dozens of servers and a significant investment in hardware, software, networking, and administration. Windows NT and UNIX Web-enablers can address mainframe applications, but they require an extra tier for the IT organization to manage. 6. Ensure security by leveraging mainframe authentication procedures and access control rules. The Web solution must ensure that mainframe information is served only to authorized users on Web browsers. By exploiting Secure Sockets Layer (SSL) technology, it is possible to encrypt all data transmitted from Web browsers to the mainframe and from the mainframe to Web browsers.

of systems management tools. As a consequence, a few people can administer a VM/ESA system that serves hundreds or thousands of E-commerce users. Hosting a Web server on VM/ESA, in combination with a Web-enabling and Web-enhancing solution, can provide the most rapid, reliable, and lowcost solution for E-commerce applications. Do not reinvent the wheel by recreating applications on alternative platforms simply to get them out on the Web. Extend and leverage investments on the mainframe by connecting them to the Web and giving them the fresh look and feel of a graphical user interface.

473

Chapter 40

Why Parallel Sysplex is a Must for Today’s IBM Data Centers Anura Gurugé

PARALLEL SYSPLEX1 IS IBM’S COGENT AND HIGHLY STRATEGIC SERVER clustering technology for contemporary mainframe systems. Introduced in 1994, Parallel Sysplex is an integral and pivotal facet of IBM’s highly successful initiative to dramatically reduce and redefine the cost of mainframe-centric computing. Parallel Sysplex permits up to 32 mainframes, with multiple copies of the operating system and application programs tightly coupled together in a fault-masking, workload-balancing mode, replete with concurrent read/write access to shared data from all of the clustered mainframes. Parallel Sysplex delivers: • exceptional scalability capable of providing over 2000 mainframe MIPS2 • nonstop operation with 99.999% uptime per year, including planned outages for preventive maintenance, which translates to less than five minutes of potential, unexpected downtime over a 24 × 7 × 52 period • smooth, transparent, “not-even-a-noticeable-hiccup,” total protection against processor, hardware, operating system, access method (e.g., ACF/VTAM), application subsystem, or application failures • seamless, policy-based load balancing between multiple instances of an application • an intriguing capability for disaster recovery, known as Geographically Dispersed Parallel Sysplex (GEOPLEX), which permits Parallel Sysplex clusters to be separated by as much as 24 miles (i.e., 40 km) Parallel Sysplex, thus persuasively and powerfully addresses the two fundamental issues crucial to the success of mainframe-based computing: unconstrained growth in capacity and ultra-high availability. Therefore, it is not surprising that, within five years of its introduction, over 2000 customers 475

SERVER INFRASTRUCTURE around the world, including huge financial institutes such as NationsBank, Fannie Mae, and BANC ONE Corporation, were already profitably exploiting the advantages of Parallel Sysplex, despite the fact that mainframe shops understandably are noted for their conservatism and deliberation when it comes to adopting new technology such as this. NationsBank, for example, was able, thanks to Parallel Sysplex, to increase its data center capacity from 720 S/390 MIPS in January 1995 to 2030 MIPS in January 1998, using just its original staff of five systems programmers. NOT YOUR FATHER’S MULTIPROCESSORS Multiprocessor systems, where the combined processing power of multiple processors is harnessed by one copy of an operating system to execute its workload, are not a new concept when it comes to IBM mainframe computing. S/370 machines based on symmetric multiprocessor (SMP) technology have been available since the late 1970s. Today, SMP is a key and integral feature of IBM’s latest mainframe family, i.e., the CMOS technologybased S/390 Parallel Enterprise Server. The word “parallel” denotes that parallelism is at the very core of these highly cost-effective mainframes. The fifth generation of these S/390 mainframes, referred to as the G5 models, started shipping in September 1998. In addition to uniprocessor models, there are G5 models for every multiprocessor permutation from 2 to 10; thus it is even possible to get G5 models with five, seven, or nine processors. Parallelism is what enabled IBM to dramatically reduce the cost of mainframe MIPS in order to address the stern challenge it faced in the late 1980s with the client/server “open systems” movement inspired by the then highly cost-competitive RISC-based UNIX systems. The high cost of mainframes in the late 1980s was not entirely due to high margin pricing on the part of IBM. The bipolar semiconductor technology then used to build its mainframe processors was in reality quite expensive compared to the CMOS3 technology used to build nearly all other processors, including those for PCs, RISC systems, and minicomputers. There were many factors that contributed to the high cost of bipolar technology. For a start, bipolar had limited economies of scale. Bipolar technology was in essence restricted to mainframe systems, whereas CMOS technology was nearly ubiquitous given its use in PCs and workstations. This meant that the innate cost of bipolar technology tended to stay on the high side, whereas the cost of CMOS-based processors continued to decrease as volumes around the world multiplied. Moreover, bipolar, which is inherently faster than CMOS, was more expensive to fabricate. If this was not enough, bipolar systems generated considerably more heat than CMOS processors, thus necessitating expensive cooling systems such as the water and liquid cooling systems that were synonymous with S/370 mainframe systems in the 1980s. 476

Why Parallel Sysplex is a Must for Today’s IBM Data Centers Given the economic reality of bipolar semiconductor technology, the only realistic way that IBM could reduce the costs of mainframes to match those of RISC/UNIX systems was to abandon bipolar in favor of CMOS. That is exactly what IBM did around 1993 with the introduction of the S/390 Parallel Enterprise Server family of mainframes. A CMOS-based S/370 central processing unit (CPU) on its own, however, could not generate as many MIPS as would have been possible if bipolar technology had been used. Thus, the only way that IBM could satisfy the ongoing, insatiable demand for mainframe MIPS was to resort to parallel processing, hence their name and the various models offering up to ten processors working in SMP mode. (Hitachi Data Systems (HDS) is committed, at least in the short- to mid-term, to continue to develop bipolar-based mainframes for customers that want more MIPS than are possible with the S/390 machines.) SMP alone, even in ten-processor mode, cannot address the number of MIPS required by the large mainframe shops. The increase in processing power with SMP is never linear. Thus, doubling the number of processors from, say, four to eight will never produce twice as much power. Instead, the best one could hope for would be an increase in the 1.7 times range, with the “markup” decreasing as the number of processors increases. This propensity for diminishing returns as the number of processors increases is the ironic “Catch-22” of SMP. In addition, business processing is typically unsuited for massively parallel processing (MPP), where hundreds of processors are harnessed together, since the processes cannot be broken into small components that can be handled by a separate processor. MPP is best-suited for certain scientific applications such as 3-D model rendering, weather forecasting, and nuclear physics simulation. IBM’s RISC technology-based RS/6000 scalable parallel (SP) systems that can have up to 512 processors cater to those customers that require MPP. In addition to the disadvantages of the “law of diminishing returns,” SMP systems, including S/390 systems, cannot provide for protection against the failure of the operating system or those of an application subsystem such as CICS or IMS. Consequently, while an SMP system will continue to work if one or more of its processors fail, the operating system, application subsystems, and the actual applications constitute single points of failure. Preventive maintenance and upgrades to the software, including the operating system, will also result in downtime, obviating the possibility of maintaining a 99.99% uptime record over a year or more. GOING BEYOND BEING JUST LOOSELY COUPLED Loosely coupled systems were the initial approach to overcoming the limitations of SMP. In a loosely coupled configuration, multiple mainframes, each running its own copy of the operating system, and application subsystems are grouped together via channel-to-channel connections. 477

SERVER INFRASTRUCTURE Each of the mainframes that are loosely coupled may in addition be SMP systems with multiple processors. Loosely coupled systems have been available in the mainframe world since way back in the late 1970s with IBM’s JES24 and JES3 job and resource sharing schemes. With a loosely coupled system, jobs in a central job input queue would be distributed across the individual mainframes. In addition, files, printers, and operator consoles would be shared across the mainframes. Loosely coupled systems thus provided additional processing capacity over individual SMP systems, as well as protection against the failure of a single operating system or application subsystem. It was also possible to perform preventive maintenance or upgrade software on one machine without losing all of one’s mainframe processing capability. Exhibit 40-1 illustrates the differences between uniprocessor, SMP, and loosely coupled configurations. In September 1990, IBM introduced Sysplex for MVS-based mainframe systems. Sysplex, now referred to as “Base Sysplex” to emphatically differentiate it from Parallel Sysplex, set out to enhance the manageability and cross-system data-sharing possibilities of loosely coupled systems. The key innovations of Sysplex, the Cross-System Coupling Facility (XCF) and the Sysplex Timer. XCF, which was in effect a feature within MVS/ESA SP4, allowed authorized applications to communicate with each other on a peer-to-peer basis across mainframe channels. Since the introduction of Sysplex coincided with the availability of the fiberoptic-based, high-speed ESCON5 channels, such XCF communications and data sharing could now be performed at speeds ranging from 10 MBytes/sec to 17 MBytes/sec (i.e., 80 Mbps to 136 Mbps). The Sysplex Timer enabled the system timers of all of the mainframes working together to be tightly synchronized. Parallel Sysplex, introduced four years later, went further than Base Sysplex in two key areas. It enabled a larger number of mainframes to be clustered together, and permitted very high-speed, read/write data sharing to facilitate workload balancing within the context of a single system image. Exhibit 40-2 depicts the general architecture of a Parallel Sysplex configuration. Today, it is possible to have up to 32 mainframes working together in a Parallel Sysplex configuration. Although very much targeted at the CMOS S/390 machines, the mainframes making up a Parallel Sysplex cluster do not necessarily have to be just S/390 machines. One can use IBM’s ES/9000 family bipolar mainframes in Parallel Sysplex configurations. Parallel Sysplex operation is also supported on certain non-IBM “plug-compatible” mainframes, most notably by HDS and Amdahl. All the mainframes making up a Parallel Sysplex cluster do not have to be of the same type; hence, it is indeed possible to have a cluster made up of S/390, ES/9000, and non-IBM mainframes.

478

but with diminishing results Processor Fault Tolerance: yes Software Fault Tolerance: none

Scalability: increases non-linearly with number of processors,

Scalability: better than that posssible with a SMP configuration Processor Fault Tolerance: yes

Exhibit 40-1. Differences between various processor grouping schemes.

Software Fault Tolerance: yes

Operating System

job queue sharing data, printer and operator console sharing

Operating System

Loosely Coupled Configurations

Scalability: restricted to power of single processor Processor Fault Tolerance: none Software Fault Tolerance: none

processors

Operating System

Operating System

processor

Symmetric Multiprocessor (SMP)

Uniprocessor

Why Parallel Sysplex is a Must for Today’s IBM Data Centers

479

480

Sysplex Timer 8 7 6 5

4

11 12 1 10 2 9 3

Shared Data

HiPerLink

Exhibit 40-2. General architecture of a parallel sysplex system.

CMOS S/390 mainframe multiple processors partitioned using LPARs

HiPerLink

IBM 9672-R06 Coupling Facility

with 1 - 10 processors

mainframes

CMOS S/390

SERVER INFRASTRUCTURE

Why Parallel Sysplex is a Must for Today’s IBM Data Centers In March 1999, the two most potent S/390 G5 models, the so-called 9672 Models RX6 and YX6,6 each contained ten processors; that is, they are ten-way SMP machines. Given that Parallel Sysplex supports up to 32 mainframes, it is indeed possible to have a “humongous” mainframe configuration with 320 separate processors by coupling together these top-end G5 models. Thus, it is no surprise that seamless scalability to effortlessly address the growing processor needs of its larger customers is invariably touted by IBM as one of the primary strengths of Parallel Sysplex. Given that transparent, nondisruptive fault masking is the other major attraction of Parallel Sysplex, the configuration and composition of these systems can obviously change dynamically, without any noticeable impact on the applications or end users. This also means that one can “hot-plug” additional mainframes into working Parallel Sysplex configuration “on-the-fly” and without any disruption to handle abnormal or peak workloads. DIVIDE AND CONQUER Although it is easier to think of Parallel Sysplex configurations as being made up of separate mainframes, this IBM clustering technology in reality is generalized enough to enable it to also be seamlessly used between processors within the same mainframe. IBM has had a hardware feature on its mainframes known as Processor Resource/System Manager (PR/SM) since the late 1980s. PR/SM, which is also available on the S/390 family, allows the resources of a single mainframe, including its complement of processors, to be subdivided into individual, autonomous “mini-mainframe” machines. This process of subdividing a mainframe into multiple units is referred to as logical partitioning (LPAR). (PR/SM is best thought of as a hardware-based equivalent to IBM’s old virtual machine [VM] operating system that permitted multiple virtual mainframes to be cloned on top of a single physical mainframe.) Separate LPARs can be included within a Parallel Sysplex configuration as if each LPAR was a bona fide stand-alone mainframe. This ability to transparently “slot-in” LPARs into a Parallel Sysplex configuration in “hot-plugin” mode can be gainfully exploited as a means of adroitly dealing with peak workloads. For example, using LPAR, one processor of a five-way S/390 could be set aside for operating system testing while the other four participate in a Parallel Sysplex configuration, along with other mainframes, that is handling the production workload. At known peak load periods such as day-end or month-end processing, operating system testing could be suspended and the processor that was devoted to it “hotplugged” into the Parallel Sysplex configuration to share the processing workload.

481

SERVER INFRASTRUCTURE The ability to use LPARs with Parallel Sysplex also provides a very convenient and elegant way by which customers can evaluate and experiment with Parallel Sysplex just using a single multiprocessor mainframe, even a “small” two-way S/390 model. This capability of running Parallel Sysplex with just one physical mainframe can also be profitably leveraged to realize exceptional protection against operating system, application subsystem, and application failures. Rather than running their applications in SMP mode on an unpartitioned mainframe, customers can now create two (or more) LPARs, run separate copies of their operating system and application software on each LPAR, and then realize workload balancing across all the processors on the mainframe using Parallel Sysplex. While there is an added cost for running such a Parallel Sysplex configuration, including the need to pay more for the software licenses (albeit with a Parallel Sysplex-specific “markdown”), this cost may be easily justifiable given the marked reduction in possible downtime. The current 320 processor limit of Parallel Sysplex is also unlikely to be an unyielding barrier for long. IBM indubitably will increase, in the future, the maximum number of mainframes possible within a Parallel Sysplex cluster. Although IBM may not go too far beyond the ten-way SMP machines given the law of diminishing returns, IBM since 1994 has been significantly increasing the power of its CMOS S/390 processors on a yearly basis. Therefore, it is safe to assume that it would indeed be a rare customer who would be able to claim that they are in imminent danger of running out of mainframe processing capacity. NONSTOP WORKING The two primary application- or software-related attributes of a Parallel Sysplex configuration are: 1. Single System Image, with the Generic Resources function, that ensures smooth workload balancing at an application subsystem (e.g., CICS) or application level across multiple mainframes (or processors if LPARs is being used). 2. Multinode Persistent Sessions (MNPS) that provide complete, nondisruptive, “not-even-a-single-keystroke-dropped” protection against processor, hardware, operating system, access method, application subsystem, or application failures. The term “persistent” in the name highlights the fact that the goal of this function is to ensure session persistence (i.e., continuity), while “multinode” describes that this persistence is realized by having multiple instances (i.e., nodes) of the components required to ensure session continuity in the event of a failure to a single node.

482

Why Parallel Sysplex is a Must for Today’s IBM Data Centers With Parallel Sysplex, every mainframe (or LPAR) in the cluster runs its own copy of the operating system access methods as well as all of the relevant software, in particular the applications or application subsystems that require load balancing and fault-protection. Thus, there will typically be multiple copies of the same application subsystem or application running concurrently on a Parallel Sysplex system. Each application or application subsystem will have its own unique name, so if there are multiple instances of the CICS subsystem running on separate mainframes, each copy would have a name such as CICS1, CICS2, CICS3, etc. The Generic Resources capability of Parallel Sysplex, however, hides these individual names from the end user. Instead, all that the user needs to know is the “generic” name associated with the application; for example, just “CICS.” Thus, all the CICS users associated with that Parallel Sysplex system will always log on to “CICS.” The Workload Manager component of the Parallel Sysplex system, which in essence permeates across all the mainframes involved, will dynamically intercept each log-on attempt to CICS. It will then determine which copy of CICS is best-suited to handle that log-on request based on current processing loads and implementationspecified policies, contingent on multiple criteria, dictating how the workload should be optimally balanced. The Workload Manager will thereupon pass the log-on to the appropriate copy of CICS, which will process the log-on and, if valid, establish a session with the user. The user will be oblivious as to which copy of CICS it is talking to. In many cases, the end users may not even know, or care, about Parallel Sysplex and that there are multiple copies of CICS in play. For the duration of that session, however, the end user will communicate directly with that copy of CICS, unless, of course, there is a failure that impacts that copy of CICS. In the event of a failure, MNPS comes to the rescue transparently and automatically. Parallel Sysplex relies on various “heartbeat” tracking mechanisms to continually monitor the availability of all of the components within the cluster. In its most basic form, a heartbeat tracking scheme could be one where each copy of a particular application sends an “I-amalive-and-well” message to all of its peers on a preset, periodic basis. If such a message is not received from a copy of an application within the expected time limit, its peers and the Workload Manager assume that there has been some type of failure. With nonstop working being paramount, the Workload Manager and the other copies of the application immediately set out to recover the end-user sessions that were being handled by the failed application. This recovery is nondisruptive and happens without any interventions from the end users, or for that matter the system operators. Invariably, the users will not be aware that there has been any type of failure

483

SERVER INFRASTRUCTURE at the data center. The only indication of the recovery process will be a slight delay in receiving the response to the last transaction entered by a user. With Parallel Sysplex, the log-on information related to every session that is established is “journaled” on disk storage, just in case the session has to be reestablished due to a failure within the system. This log-on journaling ensures that end users’ sessions can be automatically established with another copy of the application without the user having to re-logon, as is the case when MNPS is not being used. In addition to the log-on information, all input coming into an application is mandatorily stored on a shared read/write disk volume before it is passed on to its intended application. This input caching guarantees that input submitted by an end user is not lost due to application failure. The Parallel Sysplex operating system software working in conjunction with the communications access method (e.g., ACF/VTAM) also monitors the transport layer acknowledgments being issued by the application for the transactions it receives to manage the contents of this input cache. With SNA and TCP/IP, any lost message units can be recovered at the communications subsystem level without end-user intervention, provided, of course, that the recipient has not previously acknowledged the safe receipt of the message units in question. During the recovery process, all the sessions that were being handled by the failed application will be switched over to other copies of the application. An installation could specify certain policies as to how this “cutover” should be handled so that certain sessions could get priority over others. Once the sessions have been redistributed across the working copies of the application, they are automatically resynchronized to the state they were in prior to the application failure. The cached input and the acknowledgment status of the last transaction are used to realize this resynchronization. The bottom line here is that the recovery, whether from hardware, operating system, access method, application subsystem, or application failure, is quick, automatic, nondisruptive, transparent, and, above all, painless. This powerful MNPS feature of Parallel Sysplex is in effect a further refined and generalized version of the Extended Recovery Facility (XRF) that IBM has offered since 1987 to enhance the availability of mainframe-centric, mission-critical computing. With Parallel Sysplex, mainframe customers in essence get “XRF+,” in addition to load balancing and scalability. The Geographically Dispersed Parallel Sysplex feature extends the nonstop aspect of Parallel Sysplex to also embrace certain disaster recovery scenarios. With GEOPLEX, a Parallel Sysplex cluster can be spread across data centers that are 24 miles apart, connected via fiber-optic links running at speeds up to 800 bps. Critical data, including the log-on information, will be mirrored at each data center. Consequently, other remote sites can 484

Why Parallel Sysplex is a Must for Today’s IBM Data Centers continue to maintain workload processing in the event of a total catastrophic failure to one of the data centers. This type of disaster recovery set-up could be used to deal with data center failures precipitated by certain local disturbances such as earthquakes, hurricanes, terrorist attacks, riots, or accidents (e.g., plane crash). COUPLING AT ITS BEST The logical and physical connections between the mainframes and processors within a Parallel Sysplex cluster are realized via what IBM refers to as the Coupling Facility (CF). The CF in reality is the very heart and soul of the Parallel Sysplex technology and the basis for the read/write data sharing that is imperative in order to achieve the single-system image and MNPS characteristics. It is the CF that provides Parallel Sysplex systems with three key and prerequisite functions: 1. very fine granularity Data Locking to permit data sharing and data updating between multiple copies of an application without contention and loss of integrity 2. data caching, as in the case of I/O caching, on both a local and distributed basis, including high-performance data caching for the shared data access 3. queuing mechanisms to support workload distribution, message interchange, and state information sharing The CF per se consists of hardware and specialized IBM-licensed internal code (i.e., “microcode”) known as “CF Control Code” (CFCC). IBM currently provides two distinct means of implementing a CF: an integrated S/390 solution, and one that requires a separate, stand-alone box. The integrated option is known as the Internal Coupling facility (ICF), while the stand-alone CF is implemented using either an IBM 9674 box or an IBM 9672 Model R06 machine. With ICF, one uses one (or more) of the processors in a multi-processor S/390 to act as the CF and run the requisite CFCC software. The processor(s) used to run CFCC can be dedicated just for the CF function. IBM also provides the option whereby the CFCC code can run in shared mode with processors being used to support a true application partition (i.e., an LPAR). The 9674 and 9672-R06 have their own processors to run the CFCC software; both boxes can have up to ten processors. The 9672-R06, although constrained so that it can only act as a CF box, is in reality just another S/390 G5 mainframe with one to ten standard S/390 processors. Physical connectivity for data transfer between a CF and all the processors involved in a Parallel Sysplex cluster can be achieved using two very distinct mechanisms. If the CF and some of the processors are all resident within the same S/390 mainframe, high-speed communications between 485

SERVER INFRASTRUCTURE those co-resident entities can be realized using an internal channel or bus. With G5 models, the preferred option is to use the internal Self Timed Interconnect (STI) bus that runs at 333 Mbps. External links between separate S/390 mainframes (9672-R06s or 9674s) are typically implemented using the so-called HiPerLinks. HiPerLinks are IBM-specific, fiberoptic-based connections that can sustain data transfers at speeds up to 800 Mbps over distances reaching 24 miles. HiPerLinks are the basis for GEOPLEX configurations. THE BOTTOM LINE Parallel Sysplex is a pivotal feature of IBM’s ongoing mainframe strategy. S/390 Parallel Sysplex brings the power, scalability, and cost economics of large-scale parallel processing, hitherto confined to the scientific community, into the commercial sector. With today’s Parallel Sysplex, it is possible to have a tightly coupled mainframe cluster that offers smooth workload balancing, and the nonstop computing strengths of multinode persistent sessions that consist of 32 separate mainframes, each with up to ten processors. Parallel Sysplex synergistically synthesizes the best qualities of SMP and loosely coupled systems to provide scalability, 99.999% “uptime,” nonstop operation, and workload balancing. With IBM’s move to CMOS-based processors, Parallel Sysplex, as opposed to acquiring larger and larger SMP machines, is the cogent and strategic means for addressing the need for greater processing capacity. The fundamental difference between the original S/360 machines introduced in 1967 and the S/370s that came to be in 1971 was virtual storage. Today, virtual storage is very much a given and not even thought of as a value-added feature. The key difference between the S/370 and S/390 is Parallel Sysplex. Just as with virtual storage, Parallel Sysplex in the near future will become an indelible, mandatory feature of mainframe computing. Of that there can be no doubt. Notes 1. Sysplex = System Complex. 2. Million Instructions Per Second. 3. Complementary Metal Oxide Semiconductor. 4. JES = Job Entry Subsystem, job control system for the MVS operating system. 5. Enterprise System Connectivity is IBM’s current high-speed channel architecture which supports data transfers at up to 17 MB/s. 6. RX6 has a 12 GB/s memory bus, while the YX6 is even quicker with a 15 GB/s bus.

486

Section IX

System and Network Management NO DISCUSSION OF COMPUTING AND NETWORKS IS COMPLETE WITHOUT A discussion of system and network management. Web-to-host integration is no exception to this rule. With the broadening of the scope of the “enterprise network” in Web-to-host environments to include business partners and end users, the complexity of system and network management is increased. While the topic of system and network management in a Web environment could fill its own handbook, this section provides a collection of chapters that discuss some of the issues, challenges, and solutions to the management challenge in a Web-to-host environment. Chapter 41 begins with a discussion of the management of keys, which is an essential element in an overall Web-to-host security strategy. Chapter 42 discusses some basics of Web server monitoring to avoid and detect problems related to the Web server. The challenges of managing data and data warehouses is discussed in Chapters 43 through 45. For IBM mainframe-oriented environments, Chapter 46 touches on issues and solutions for managing a WAN environment in a mainframe-centric enterprise.

487

Chapter 41

Principles and Applications of Key Management William H. Murray

CRYPTOGRAPHY

IS THE USE OF SECRET CODES TO HIDE DATA AND TO

authenticate its origin and content. While public codes could be used to authenticate content, secret codes are necessary to authenticate origin. This latter use of cryptography has emerged only in the latter half of the last century and has been surprising to all but a few. Of all security mechanisms, cryptography is the one most suited to open and hostile environments, environments where control is otherwise limited, environments like the modern, open, flat, broadcast, packetswitched, heterogeneous networks. Cryptography is broadly applicable. In the presence of cheap computing power, its uses are limited only by our imaginations. Given that most of the power of our computers goes unused, one could use secret codes by default, converting to public codes only for use. Indeed, the modern distributed computing systems and applications would be impossible without it. It is portable: the necessary software to encode or decode the information can be distributed at or near the time of use in the same package and channel. Within minor limits, it is composable. Different functions and algorithms can be put together without losing any strength. One can put together mechanisms to emulate any environmental or media-based control. Not only is cryptography effective, it is efficient. That is to say, it is usually the cheapest way to achieve a specified degree of protection. The cost of cryptography is low. Not only is it low in absolute terms, but also in terms of the security value that it delivers. It is low when compared to the value of the data that it protects. It is low when compared to the alternative ways of achieving the same degree of security by such alternative means as custody, supervision, or automated access control. 489

SYSTEM AND NETWORK MANAGEMENT The low cost of cryptography is the result, in part, of the low cost of the modern computer and is falling along with the cost of computing. The cost of a single cryptographic operation today is one ten-thousandth of what it was as recently as 20 years ago and can be expected to continue to fall. Another way of looking at it is that its relative strength is rising when cost is held constant, and the cost to the user is falling relative to the cost to the attacker. As will be seen, automated key management is one mechanism that permits us to trade the increasing power of computing for increased security. Modern cryptography is arbitrarily strong; that is, it is as strong as needed. If one knows what data one wishes to protect, for how long, and from whom, then it is possible to use modern cryptography to achieve the desired protection. There are limitations; if one wanted to encrypt tens of gigabytes of data for centuries, it is difficult to know how to achieve that. However, this is a theoretical rather than a practical problem. In practice, there are no such applications or problems. Cryptography is significantly stronger than other security mechanisms and will rarely, if ever, be the weak link in the security chain. However, in practice, its strength is limited by the other links in the chain; for example, key management. As it is not efficient to make one link in a chain significantly stronger than another, so it is not necessary for cryptography to be more than a few hundred times stronger than the other mechanisms on which the safety of the data depends. The cryptography component of a security solution is robust and resilient — not likely to break. Although history suggests that advances in technology may lower the cost of attack against a particular cryptographic mechanism, it also suggests that cost does not drop suddenly or precipitously. It is unlikely to collapse. Given the relative effectiveness and efficiency of cryptography relative to other security measures, changes in the cost of attack against cryptography are unlikely to put security at risk. The impact is obvious and there is sufficient opportunity to compensate. Changes in technology reduce the cost to both the user of cryptography and the attacker. Because the attacker enjoys economies of scale, advances such as the computer historically have favored the attacker first and the user second. However, that probably changed forever when both the scale and the cost of the computer fell to within the discretion of an individual. Further advances in technology are likely to favor the cryptographer. As one will see, as the cost of attack falls, the user will spend a little money to compensate. However, it is in the nature of cryptography that as costs to the user rise linearly, the costs to the attacker rise exponentially. For example, the cost of attack against the data encryption standard (DES) has fallen to roughly a million MIPS years. While this is still adequate for 490

Principles and Applications of Key Management most applications, some users have begun to use Triple DES-112. This may quadruple their cost but increase the cost of a brute force attack by 255. One way of looking at cryptography is that it changes the problem of maintaining the secrecy of the message to one of maintaining the secrecy of the keys. How this is done is called key management. KEY MANAGEMENT DEFINED Key management can be defined as the generation, recording, transcription, distribution, installation, storage, change, disposition, and control of cryptographic keys. History suggests that key management is very important: each of these steps is an opportunity to compromise the cryptographic system. Further, it suggests that attacks against keys and key management are far more likely and efficient than attacks against algorithms. Key management is not obvious or intuitive. It is very easy to get wrong. For example, students found that a recent release of Netscape’s SSL implementation chose the key from a recognizable subspace of the total key space. While the total space would have been prohibitively expensive to exhaust, the subspace was quite easy. Key management provides all kinds of opportunities for these kinds of errors. As a consequence, key management must be rigorous and disciplined. History tells us that is extremely difficult to accomplish. The most productive cryptanalytic attacks in history, such as ULTRA, have exploited poor key management. Modern automated key management attempts to use the computer to provide the necessary rigor and discipline. Moreover, it can be used to compensate for the inherent limitations in algorithms. MODERN KEY MANAGEMENT Modern key management was invented by an IBM team in the 1970s.1 It was described in the IBM Systems Journal 2 at the same time as the publication of the DES. However, while the DES has inspired great notice, comment, and research, key management has not received the recognition it deserves. While commentators were complaining about the length of the DES key, IBM was treating it as a solved problem; they always knew how to compensate for fixed key length and believed that they had told the world. Modern key management is fully automated; manual steps are neither required nor permitted. Users do not select, communicate, or transcribe keys. Not only would such steps require the user to know the key and permit him to disclose it accidentally or deliberately, but the steps would also be very error prone. Modern key management permits and facilitates frequent key changes. For example, most modern systems provide that a different key will be used for each object, e.g., file, session, message, or transaction to be encrypted. 491

SYSTEM AND NETWORK MANAGEMENT Manual systems of key management were always in a difficult bind: the more often the key was changed, the greater the opportunity for error and compromise. On the other hand, the more data that was encrypted under a single key, the easier the key was to attack and the more data was compromised with that key. To change or not to change: how to decide? Automating the system changes the balance. It permits frequent secure key changes that raise the cost of attack to the cryptanalyst. The more keys used for a given amount of data, the higher the cost of attack, more keys to be found, and the lower the value of success, the less data for each key. All other things equal, as the number of keys increases, the cost of attack approaches infinity and the value of success approaches zero. The cost of changing keys increases the cost of encryption linearly but it increases the cost of attack exponentially. All other things equal, changing keys increases the effective key length of an algorithm. Because many algorithms employ a fixed-length key, because one can almost always find the key in use by exhausting the finite set of keys, and because the falling cost and increasing speed of computers is always lowering the cost and elapsed time for such an attack, the finite length of the key might be a serious limitation on the effectiveness of the algorithm. In the world of the Internet, in which thousands of computers have been used simultaneously to find one key, it is at least conceivable that one might find the key within its useful life. Automatic key change compensates for this limit. A recent challenge key3 was found using more than 10,000 computers for months at the rate of billions of keys per second and a million MIPs years per key. The value of success was only $10,000. By definition, the life of a challenge key is equal to the duration of attack. Automated key management enables us to keep the life of most keys to minutes to days rather than days to months. However, modern key management has other advantages in addition to greater effective key length and shorter life. It can be used to ensure the involvement of multiple people in sensitive duties. For example, the Visa master key is stored in San Francisco inside a box called the BBN SafeKeyper. It was created inside that box and no one knows what it is. Beneficial use of the key requires possession of the box and its three physical keys. Because it is at least conceivable that the box could be destroyed, it has exported information about the key. Five trustees share that information in such a way that any three of them, using another SafeKeyper box, could reconstruct the key. Key management can also be used to reduce the risk associated with a lost or damaged key. While in a communication application there is no need to worry about lost keys, in a file encryption application, a lost key 492

Principles and Applications of Key Management might be the equivalent of loss of the data. Key management can protect against that. For example, one of my colleagues has information about one of my keys that would enable him to recover it if anything should happen to me. In this case, he can recover the key, but the implementation that we are using permits me to specify how many people must participate in recovering the key. Key management may be a stand-alone computer application or it can be integrated into another application. IBM markets a product that banks can use to manage keys across banks and applications. NetScape Navigator and Lotus Notes have key management built in. Key management provides the protection for keys in storage and during exchange. Smart cards may be used to accomplish this. For example, if one wishes to exchange a key with another, one can put it in a smart card and mail it. PRINCIPLES OF KEY MANAGEMENT A number of principles guide the use and implementation of key management. These principles are necessary, but may not be sufficient for safe implementation. That is, even implementations that adhere to these principles may be weak, but all implementations that do not adhere to these principles are weak. First, key management must be fully automated. There may not be any manual operations. This principle is necessary both for discipline and for the secrecy of the keys. Second, no key may ever appear in the clear outside a cryptographic device. This principle is necessary for the secrecy of the keys. It also resists known-plain-text attacks against keys. Keys Must Be Randomly Chosen from the Entire Key Space If there is any pattern to the manner in which keys are chosen, this pattern can be exploited by an attacker to reduce his work. If the keys are drawn in such a way that all possible keys do not have an equal opportunity to be drawn, then the work of the attacker is reduced. For example, if keys are chosen so as to correspond to natural language words, then only keys that have such a correspondence, rather than the whole space, must be searched. Key-Encrypting Keys Must Be Separate from Data Keys Keys used to encrypt other keys must not be used to encrypt data, and vice versa. Nothing that has ever appeared in the clear can be encrypted under a key-encrypting key. If keys are truly chosen randomly and are never used to encrypt anything that has appeared in the clear, then they are 493

SYSTEM AND NETWORK MANAGEMENT not vulnerable to an exhaustive or brute-force attack. To understand this, it is necessary to understand how a brute-force attack works. In a brute-force attack, keys are tried one after another until the key in use is found. The problem that the attacker has is that he must be able to recognize the correct key when he tries it. There are two ways to do this, corresponding clear and cipher text attacks, and cipher text-only attacks. In the former, the attacker keeps trying keys on the cipher text until he finds the one that produces the expected clear text. At a minimum, the attacker must have a copy of the algorithm and a copy of the cryptogram. In modern cryptography, the algorithm is assumed to be public. Encrypted keys will sometimes appear in the environment and encrypted data — cipher text — is expected to appear there. For the first attack, the attacker must have corresponding clear and cipher text. In historical cryptography, when keys were used widely or for an extended period of time, the attacker could get corresponding clear and cipher text by duping the cryptographer into encrypting a message that he already knew. In modern cryptography, where a key is used only once and then discarded, this is much more difficult. In the cipher text-only attack, the attacker tries a key on the cipher text until it produces recognizable clear text. Clear text may be recognized because it is not random. In the recent RSA DES Key Challenge, the correct clear-text message could be recognized because the message was known to begin with the words “The correct message is ….” However, even if this was not the case, the message would have been recognizable because it was encoded in ASCII. To resist cipher text-only attacks, good practice requires that all such patterns as format, e.g., file or E-mail message, language (e.g., English), alphabet (e.g., Roman), and public code (e.g., ASCII or EBCDIC) in the cleartext object must be disguised before the object is encrypted. Note that neither attack will work on a key-encrypting key if the principles of key management are used. The first attack cannot succeed because the crypto engine cannot be duped into encrypting a known value under a key-encrypting key. It will only encrypt a random value, which it produced inside itself, under a key-encrypting key. The cipher text-only attack cannot be made to work because there is no information in the clear-text key that will be recognized by the attacker. That is, the clear-text key is, by definition, totally random, without recognizable pattern, information, or entropy. Keys with a Long Life Must Be Sparsely Used There are keys, such as the Visa master key mentioned earlier, whose application is such that a very long life is desirable. As we have already noted, 494

Principles and Applications of Key Management the more that a key is used, the more likely a successful attack and the greater the consequences of its compromise. Therefore, one compensates by using this key very sparsely and only for a few other keys. There is so little data encrypted under this key and that data so narrowly held, that a successful attack is unlikely. Because only this limited number of keys is encrypted under this key, changing it is not prohibitively expensive. ASYMMETRIC KEY CRYPTOGRAPHY Perhaps the most novel and unexpected cryptographic invention of modern cryptography is asymmetric key cryptography. In this kind of cryptography, the key has two parts; the parts are mathematically related to each other in such a way that what is encrypted with one part can only be decrypted by the other. Only one part, called the private key, is secret. The other part, the public key, is published to the world. Anyone can use the public key to encrypt a message that can only be decrypted and read by the owner of the private key. Conversely, anyone can read a message encrypted with the private key, but only the person with beneficial use of that key could have encrypted it. For example, if A and B share a symmetric key, then either knows that a message encrypted under that key originated with the other. A change in as little as one bit of the message will cause it to decrypt to garbage and therefore the receiver knows if the message has been tampered with. However, because each has beneficial use of the key and could have created the cryptogram, they cannot demonstrate that it originated with the other. In asymmetric key cryptography, only the possessor of the private key could have created the cryptogram. Any message that will decrypt with the public key therefore is known to have originated with the person who published it. This mechanism provides a digital signature capability that is independent of medium and far more resistant to forgery than marks on paper. While key management can be accomplished using only symmetric key cryptography, it requires secret key exchange, a closed population, some prearrangement, and benefits greatly from trusted hardware. Asymmetric key cryptography enables key management without secret key exchange in an open population with a minimum of prearrangement. It reduces the need for trusted hardware for key distribution, although it is still desirable for key storage and transcription. However, when otherwise compared to symmetric key cryptography, asymmetric key cryptography comes up short. It requires much longer keys to achieve the same computational resistance to attack (i.e., to achieve the same security). It takes much longer to generate a key. It is much slower and its performance is not linear with the length of the object to be encrypted. However, for keys that are to be used for a long period of 495

SYSTEM AND NETWORK MANAGEMENT time, the time required to generate a key is not an issue. For short objects to be encrypted, performance is not an issue. Therefore, asymmetric key cryptography is well-suited to key management applications and in practice its use is limited to that role. Most products use symmetric key cryptography to encrypt files, messages, sessions, and other objects but use asymmetric key cryptography to exchange and protect keys. IMPLEMENTATIONS This section discusses a number of products that illustrate the power, use, and limitations of modern key management. The purpose of this discussion is to make points about key management, and will not provide a complete discussion of any of the products. The products are used only for their value as examples. The order of presentation is chosen for illustrative purposes rather than to imply importance. Kerberos Key Distribution Center The Kerberos key distribution center (KDC) is a trusted server to permit any two processes that it knows about to obtain copies of a session key. Kerberos shares a secret with every process or principal in the population. When A wants to talk to B, it requests a key from the KDC. The KDC takes a random number and encrypts it under the secret that it shares with B, appends a second copy of the key, and encrypts the result under the secret that it shares with A. It broadcasts the result into the network addressed to A. A uses the secret that it shares with the KDC to recover its copy of the key and B’s copy (encrypted under the secret that B shares with the KDC). It broadcasts B’s copy into the network, addressed to B. While everyone in the network can see the messages, only A and B can use them. B uses its secret to recover its copy of the key. Now A and B share a key that both can use to talk securely to each other. This process requires that the KDC be fully trusted to vouch for the identity of A and B, but not to divulge the secrets or the key to other processes or even to use it itself. If the KDC is compromised, all of the secrets will have to be changed, i.e., the principals must all be re-enrolled. These limitations could be reduced if, instead of keeping a copy of the secret shared with the principals, the KDC kept only their public key. Then whatever other remedies might be necessary if the KDC were compromised, there would be no necessity to change the secrets. PGP PGP stands for Phil’s Pretty Good Privacy. Phil Zimmerman, its author, has received honors and awards for this product, not so much because of its elegant design and implementation as for the power of encryption that 496

Principles and Applications of Key Management it gave to the masses. It is the encryption mechanism of choice for confidential communication among individuals. PGP is implemented exclusively in software. It is available in source code and implementations are available for all popular personal computers. It is available for download from servers all over the world and is free for private use. It is used to encrypt files for protection on the storage of the local system and to encrypt messages to be sent across a distance. It uses a block cipher, IDEA, with a 128-bit key to encrypt files or messages. It automatically generates a new block cipher key for each file or message to be encrypted. It uses an asymmetric key algorithm, Rivest-ShamirAdelman (RSA), to safely exchange this key with the intended recipient by encrypting it using the recipient’s public key. Only the intended recipient, by definition the person who has beneficial use of the mathematically corresponding private key, can recover the block cipher key and the message. The principles of key management require that the user’s private key not be stored in the clear, and therefore it is stored encrypted under the block cipher. The key for this step is not stored but is generated every time it is needed by compressing to 128 bits an arbitrarily long passphrase chosen by the owner of the private key. Thus, beneficial use of the private key requires both a copy of the encrypted key and knowledge of the passphrase. Although PGP does not require secret exchange of a key in advance, it does require that the public key be securely acquired. That is, it must be obtained in a manner that preserves confidence that it is the key of the intended recipient. The easiest way to do this is to obtain it directly, hand-to-hand, from that recipient. However, PGP has features to preserve confidence while passing the public key via e-mail, public servers, or third parties. Note that if the passphrase is forgotten, the legitimate owner will have lost beneficial use of the private key and all message or file keys hidden using the public key. For communication encryption, the remedy is simply to generate a new key-pair, publish the new public key, and have the originator resend the message using the new key. However, for file encryption, access to the file is lost. As one will see, commercial products use key management to provide a remedy for this contingency. ViaCrypt PGP, Business Edition ViaCrypt PGP, Business Edition, is licensed for business or commercial use and includes emergency key recovery features to address some of the limitations of PGP previously noted. Instead of encrypting the private key under a key generated on-the-fly from the passphrase, it introduces another level of key. This key will be used to encrypt the private key and will itself be hidden using the passphrases of the owners of the private key. 497

SYSTEM AND NETWORK MANAGEMENT This may be the sole user or it may be an employee and managers representing their employer. Should one passphrase be forgotten, the other can be used to recover the private key and the files. The employee is protected from management abuse of the private key by the fact that he has possession of it, while management only has possession of a copy of the key used to hide it. However, both employees and management are protected from the consequences of loss of a single passphrase. RSA SecurePC RSA Secure PC is an add-in to the Windows file manager that is used for file encryption. It has features that extend the ideas in PGP BE and illustrate some other uses of key management. It encrypts specified files, directories, or folders, on command by marking and clicking, or by default by marking a file or directory and indicating that everything in it is always to be encrypted. Marking the root of a drive would result in all files on the drive, except executables, always being stored in encrypted form. The object of encryption is always the individual file rather than the drive or the directory. When a file is initially encrypted, the system generates a 64-bit block cipher key to be used to encrypt the file. This file key is then encrypted using the public key of the system and is stored with the file. The private key for the system is stored encrypted using a two-level key system and passphrase as in PGP BE. To read an encrypted file, the user must have the file key in the clear. To get that, the user must have the private key in the clear. Therefore, when opening a file, the system looks to see if the private key is in the clear in its memory. If not, then the user is prompted for his passphrase so that the private key can be recovered. At the time of this prompt, the user is asked to confirm or set the length of time that the private key is to be kept in the clear in system memory. The default is five minutes. Setting it to zero means that the user will be prompted for a second use. The maximum is eight hours. The lower the user sets the time that the key may remain in memory, the more secure; the higher the user sets it, the less often he will be prompted for the passphrase. RSA SecurePC also implements emergency key recovery features. These features go beyond those described: management may specify that multiple parties must be involved in recovering the private key. These features not only permit management to specify the minimum number of parties that must be involved, but also permit them to specify a larger set from which the minimum may be chosen. Multi-party emergency key recovery provides both the user and management with greater protection against abuse. BBN SafeKeyper BBN SafeKeyper is book-size hardware box for generating and protecting private keys. It generates a private key/public key pair. The private key 498

Principles and Applications of Key Management cannot be removed from the box. Beneficial use of the key requires possession of the box and its three physical keys. SafeKeyper is intended for the root key for institutions. The box has a unique identity and a public key belonging to BBN. After it generates its key-pair, it encrypts its public key and its identity under the public key of BBN and broadcasts it into the network addressed to BBN. When BBN recovers the key, it uses its own private key to create a certificate for the SafeKeyper that vouches for the bind between the public key and the identity of the person or institution to whom BBN sold the box. Although the SafeKeyper box is very robust, it is still conceivable that it could be destroyed and its key lost. Therefore, it implements emergency key recovery. While it is not possible to make an arbitrary copy of its key, it will publish sufficient information about its key to enable another SafeKeyper box to recreate it. For example, information about the Visa masterkey is held by five people. Any three of them acting in concert can reproduce this key. We will defer the discussion of one more implementations, SSL, until after the following discussion of public key certificates. Public Key Certificates By definition, public keys do not need to be kept secret. However, it is necessary to ensure that one is using the correct public key. One must obtain the key in a way that preserves confidence that it is the right key. As already noted, the best way is to obtain the key directly from the party. However, in practice, one will get public keys at the time of use and in the most expeditious manner. As with traditional signatures, one relies on a trusted third party to vouch for the association between a particular key and a particular person or institution. For example, the state issues credentials that vouch for the bind between a photo, name and address, and a signature. This may be a driver’s license or a passport. Similar credentials, called public key certificates, will be issued for public keys by the same kinds of institutions that issue credentials today: employers, banks, credit card companies, telephone companies, state departments of motor vehicles, health insurers, and nation states. A public key certificate is a credential that vouches for the bind or join between a legal person and a public key/private key pair. It contains the identifiers of the key-pair owner and the public half of the key-pair. It is signed by the private key of the issuing authority and can be checked using the authority’s public key. In addition to the identifiers of the owner and the key, it may also contain start and end dates, and its intended purpose, use, and limitations. Like other credentials, it is revocable at the discretion 499

SYSTEM AND NETWORK MANAGEMENT of the issuer and used at the discretion of the owner. Like other credentials, it is likely to be one of several and may be used in combination with others. Credential issuers or certification authorities (CAs) are legal persons trusted by others to vouch for the bind, join, or association between a public key and another person or entity. The CA may be a principal, such as the management of a company, a bank, or a credit card company. It may be the secretary of a club or other voluntary association such as a bank clearing house. It may be a government agency or designee such as the post office or a notary public. It may be an independent third party operating as a fiduciary and for a profit. The principal requirement for a certification authority is that it must be trusted by those who will use the certificate and for the purpose for which the certificate is intended. The necessary trust may come from its role, independence, affinity, reputation, contract, or other legal obligation. Secure Socket Layer (SSL) SSL is both an application programming interface (API) and a protocol intended for end-to-end encryption in client/server applications across an arbitrary network. The protocol was developed by Netscape and the Navigator browser is its reference implementation. It uses public key certificates to authenticate the server to the client and, optionally, the client to the server. When the browser connects to the secure server, the server sends its public key along with a certificate issued by a public certification authority. The browser automatically uses the issuers public key to check the certificate and manifests this by setting the URL to that of the server. It then uses the server’s public key to negotiate a session key to be used for the session. It manifests this by setting a solid key icon in the lower left-hand corner of the screen. Optionally, the client can send its public and a certificate for that key issued by the management of the server or a certification authority trusted by the management. RECOMMENDATIONS FOR KEY MANAGEMENT • To ensure rigor and discipline, automate all encryption, particularly including key management; hide all encryption from users. • To resist disclosure or arbitrary copies of a key, prefer trusted hardware for key storage. Prefer evaluated FIPS-1404 hardware, dedicated single-application-only machines (such as those from Atalla, BBN, Cylink, and Zergo), smart cards, PCMCIA cards, laptops, diskettes, and trusted desktops, in that order. As a general rule, one should discourage the use of multi-user systems for key storage except for keys that are the property of the system owner or manager (e.g., payroll manager key). 500

Principles and Applications of Key Management • Prefer one copy of a key. Avoid strategies that require multiple copies of a key. Every copy of a key increases the potential for disclosure. For example, rather than replicating a single key across multiple servers, use different keys on each server with a certificate from a common source. • Change keys for each file, message, session, or other object. • Prefer one key per use or application rather than sharing a key across multiple uses. The more data that is encrypted under a single key, the greater the potential for successful cryptanalysis and the more damaging the consequences. With modern key management, keys are cheap. • To reduce the consequences of forgotten passphrases, use emergency key recovery for file encryption applications. Do not use emergency key recovery for communication encryption; change the key and resend the message. • Employ multi-party control for emergency key recovery; this reduces the potential for abuse, improves accountability, and increases trust all around. Consider requiring that the parties come from different levels of management and from different business or staff functions. • Prefer closed and trusted processes for key generation to ensure that keys are randomly selected from the entire key space. Avoid any manual operations in key selection. • Prefer encryption and key management that are integrated into the application. The easiest way to hide encryption from the user and to avoid errors is to integrate the encryption into the application. • Prefer applications with integrated encryption and key management. No serious business applications can be done in the modern network environment without encryption. Integrated encryption is a mark of good design. Notes 1. Dr. Dorothy Denning has told me privately that key management was invented by the National Security Agency prior to IBM. Whether or not that is true is classified. In the absence of contemporaneous publication, it is unknowable. However, even if it is true, their invention did not ever make a difference; as far as we know, it never appeared in a system or an implementation, while the IBM team implemented theirs and it has made a huge difference. 2. Elander et al., Systems Journal, IBM pub G321-5066: “A Cryptographic Key Management Scheme,” 1977. 3. RSA $10,000 Challenge, http://www.frii.com/~rcv/deschall.htm. 4. Federal Information Processing Standard 140, http://csrc.ncsl.nist.gov/fips/fips1401.htm.

501

Chapter 42

Web Server Monitoring WRQ, Inc.

THIS CHAPTER PROVIDES AN INTRODUCTION TO WEB SERVER MONITORING. It describes the risks of running critical Web sites and how monitoring can reduce such risks. There are many different components in a Web site. Different strategies are used for monitoring and running proactive tests to ensure the entire site is operating correctly. Once a monitoring system is in place, the data is used in real-time for fixing and diagnosing problems. Historical data is used to predict future problems and in capacity planning. WHY MONITORING IS IMPORTANT A well-designed and smoothly operating Web site is a strategic advantage in today’s information age competition. On the Internet, the only hard currency is attention. A Web site that fails to deliver its content, either in a timely manner or at all, will cause visitors to quickly lose interest, and the time and money spent on the site’s development will be wasted. Ensuring that all of the elements of a Web site are functioning properly is critical to maximizing a company’s Web investment. If the first indication of a Web site failure is an irate customer call (or even good natured e-mail), it is already too late. When inevitable failures do occur, downtime must be minimized. When a corporate Web site fails, visitors can quickly change from potential customers to disinterested passers-by. One of the primary advantages of a corporate Web site is its ability to reach customers around the world 24 hours a day, seven days a week. A site that is down is not fulfilling that potential. When an internal Web server goes down, important lines of intra-company communication are severed. If prolonged failures are common, corporate culture may begin to shift to depend less on these highly effective communications tools, minimizing the usefulness of the investment in these technologies.

0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

503

SYSTEM AND NETWORK MANAGEMENT WEB SERVER MONITORING: AN INTRODUCTION After a Web site has been designed, created, and deployed, it must be maintained and operated. A critical element of day-to-day Web site operation is the monitoring of Web site components. Web server monitoring performs several important functions. It: • • • •

ensures that all components of the Web site are functioning properly enables quick and accurate diagnosis of problems when they do occur measures performance to give hard data for capacity planning aids in predicting possible problems or needs for increased resources

Monitoring and diagnosis are especially important. Because of the distributed nature of the Internet, failures can occur at many points, some of which are outside a Web site’s control. Being able to quickly ascertain which components are functioning and which have failed can dramatically reduce the time taken to diagnose the problem. Once the Web site is back up and functioning, hard data can be used to inform customers and management of the true cause of a given failure. Problem prevention is also a valuable function of monitoring. For example, full disks typically cause a host of problems for applications and operating systems. Simply knowing that a disk is nearing capacity may save a system administrator hours of time fixing the problems caused by a full disk — not to mention heading off the inevitable flood of user reports. A monitor is a process that performs a test, typically a diagnostic command or emulation of actual use of the system, and records the results so that they can be acted upon if required. Monitors check components on a periodic basis, frequently enough to catch failures in a timely manner, but not so frequently as to significantly impact system resources such as CPU or network bandwidth. Monitoring systems consist of a set of monitors, usually spread across multiple machines, a mechanism for alerting Web administrators if failures occur, and a log of data collected by the monitors (preferably viewable in a graphical form). In certain cases, a corrective action can be performed automatically in response to detected problems, thereby eliminating the need for human intervention. IDENTIFYING CRITICAL WEB SERVER COMPONENTS Although each Web site has different monitoring requirements, there is a core set of components that are critical to the operation of any Web site (see Exhibit 42-1). Failure of any of these components can make the Web site inaccessible, leaving potential visitors with their only impression of the site being a browser error. If monitoring is automated, ensuring that the monitoring machines and software are functioning is critical. Automated monitors installed on multiple 504

Web Server Monitoring Exhibit 42-1. Critical Web site components. Component

Proper Operation

Web server machine

The machine that the Web server is running on has not crashed, has not become overloaded, and is reachable from the network The Web server process is running and serving pages Important pages (such as the home page) exist and are retrievable without error The scripts and programs are functioning and returning acceptable pages Pings out to the Internet work, and routers between the Web site and the backbone are functioning properly Free space is at a safe level

Web server process Critical Web pages Critical CGI scripts/programs Connectivity to the Internet backbone Disk space usage

Exhibit 42-2. Important Web site components. Machines Domain Name Server (DNS) Routers Database servers File servers

Network DNS lookups Dial-up ports usage Number of socket connections Various network attacks

Processes FTP server Proxy server E-mail server News server Database process Telnet server

Web site All pages, links, and CGIs Links to external pages Files Log file sizes Temporary file sizes

machines can cross-check each other and ensure that a single failure cannot entirely disable monitoring. Besides these basic items, many Web sites have a variety of other important components that are vital to the health of the site (see Exhibit 42-2). MONITORING STRATEGY The focus of Web site monitors covers a broad spectrum, from very general monitors that test many components of a Web site simultaneously (called “holistic” monitors), to single-purpose monitors that may measure a single aspect of a single component. Holistic monitors are good indicators that either a large set of components are functioning properly, or that something is wrong with at least one of them (although getting the detailed information on problems can be difficult with these types of monitors). Focused monitors, by comparison, indicate precisely when a given component is in trouble. In practice, a combination of holistic and focused monitors provides the most effective and understandable picture of a Web site’s current state. 505

SYSTEM AND NETWORK MANAGEMENT One common holistic test is to attempt to retrieve a URL, recording any errors that may occur and the amount of time the retrieval took. This can be done manually, using a browser to retrieve the page, or automatically, using a monitoring tool. A successful retrieval is an indication that many of the critical components discussed previously are functioning properly. Failures can occur for a number of reasons — some easier to diagnose than others. For example, if a page returns a “Not Found” error, then a fairly good assumption can be made that the referenced Web page was either deleted or renamed. However, if making a connection “hangs” (takes so long that the client times out and gives up), then the problem may lie in a dead Web server process, a crashed Web server machine, or an overloaded Web server. If the retrieval was done from a client located remotely on the Internet, any of the Internet links or routers between the client and the server may have been congested or broken. Narrowing down the problem space is critical because there are some classes of problems over which a Web administrator has no control. Malfunctions or congestion in the Internet service provider’s (ISP) connections to the backbone (on either the server or client end), or with the backbone itself, cannot be fixed by a Web administrator (other than switching ISPs if problems persist). Other problems, such as a stopped Web server process, can be remedied quickly and easily — even automatically. Using a series of more focused monitors in conjunction with the holistic monitors gives overlapping coverage and allows quicker diagnosis of problems. The following are examples of common focused monitors. • ping monitor: tests whether a machine is reachable over the network, and whether the target machine is functioning well enough to send a simple reply • process monitor: ensures that a process is still active • disk space monitor: measures the percentage of disk used to prevent full disks • CPU monitor: measures the utilization of the CPU to flag chronic overloading To create good overlapping coverage, all of these monitors are used together to create the best picture of what is happening. For example, a holistic URL monitor would commonly be paired with several focused monitors such as a process monitor, a disk space monitor, a CPU monitor, and several ping monitors. The URL monitor would verify that a page could be retrieved from the server while the process monitor would verify that the Web server process was still running. The disk space and CPU monitors would ensure that resources on the server were not overloaded. The ping monitors would check network connectivity between the Web server and the router, the ISP, the backbone, and several remote sites on the Internet. 506

Web Server Monitoring The addition of other specialized monitors can increase the breadth of monitoring coverage even further, and help to more quickly narrow the focus of a problem diagnosis. Some examples of other specialized monitors include: • Domain Name Server (DNS) lookup: ensures that the DNS is properly resolving host names • router status: checks whether the router is functioning properly • database status: checks whether a database is returning correct information in a timely manner • file and directory sizes: ensures that given files (i.e., log files) do not grow too large, or that directories that should be cleaned out periodically (i.e., mail server queues) are handled properly • Web server performance: measures bytes transferred per minute, hits per minute, and other performance measures INTERNAL VERSUS REMOTE MONITORING Remote monitoring is done by machines that are outside a site’s internal network. An example of a remote monitor would be one that fetched a public URL from the Web server. Monitoring that occurs on a Web server itself, or from a machine on the internal network, is internal monitoring. The advantages of internal monitoring are that: • It is closer to the source of addressable problems. Internal monitoring keeps confounding factors such as ISP or backbone failures from obscuring site-specific problems. Because of the finer granularity of measurements possible, more precise problem diagnosis can be achieved. Problems detected by internal monitoring can generally be corrected by people at the site because they control the machines and the networks. • It allows automatic corrective actions to be taken. Internal monitors, especially those running on the servers they are monitoring, have the direct access required to take actions. Remote monitors usually do not have the security access required to initiate actions. • It is more reliable. Internal monitoring does not depend on other networks to monitor and deliver data. • It is easier to administer. Internal monitoring software and configuration are on directly accessible machines. Remote monitoring has its own set of benefits: • It detects problems not visible internally. It can detect certain classes of problems that cannot be readily detected internally. • It provides truer access time measurements. Access time measurements taken remotely are a truer reflection of the end user’s experience than measurements taken from internal machines. 507

SYSTEM AND NETWORK MANAGEMENT • It detects configuration errors that affect external users. Configuration errors in Web servers, firewalls, proxy servers, and routers may permit access from internal machines to internal sites, but may prevent legitimate external users from reaching a Web site. • It detects problems with ISP and backbone links. Testing connectivity from sites out on the Internet can also help detect failures in ISP or backbone links that may be affecting users’ ability to access the Web site. An ideal solution implements both internal and remote monitoring. Internal monitoring is primarily used to keep systems running and diagnosing problems. Remote monitoring is primarily used for measuring end-user response times and detecting problems with external connections. Remote monitoring also serves as a valuable backup monitoring system. As an example, a power failure could crash or disable all of the machines at a site. Without some monitoring from the outside, this failure would not be detected. MANAGING PROBLEMS WHEN THEY OCCUR After a problem is detected, the person(s) responsible for the equipment or function in question must be notified, typically via e-mail or pager. The faster this person is notified, the greater the chance that the problem can be fixed before customers or users are affected. When implementing a notification scheme, it is important to remember that if the scheme can be disabled by the same problems that are being monitored, notification may not succeed. For example, if e-mail is used to trigger a pager message, and the e-mail server, or the connection to the e-mail server, has problems, the pager message will not get sent. Better than notification is the ability to automatically correct problems. A hung Web server might be automatically restarted, a nearly full disk might have temporary files automatically cleaned off of it, or a flaky machine might be automatically rebooted. Automatically correcting as many problems as possible ensures minimum downtime, and reduces the need for human intervention. Note that for most corrective actions to be taken, some element of the Web server monitor must be running on the target machine. COLLECTING AND USING HISTORICAL DATA Historical data allows the correlation of several sets of monitor readings, which may lead to a quicker diagnosis of problems. For example, if the CPU utilization of the Web server is very high, then failures to retrieve URLs during that period of time may be related to Web server overload rather than the failure of a component. Preventative maintenance is one use of historical data. If a disk space usage monitor indicates a disk is filling up, steps can be taken to determine 508

Web Server Monitoring the root cause well before the problem becomes critical. Cyclical patterns of usage may also be revealed. A nightly maintenance process might create temporary files that bring the disk perilously close to capacity, and then delete those files before anyone notices. Historical data can be used for capacity planning. By looking at summary reports for recent weeks and months, the trends can be used to estimate future needs. The planning allows time for an orderly upgrade. Without planning, upgrades are rushed into place during a crisis when the system reaches capacity. Capacity planning can be used for simple upgrades like adding more disk or memory. It can also be used to schedule more complicated upgrades, such are adding additional servers or improving Internet connections. IMPLEMENTING A WEB MONITORING STRATEGY There are several ways to implement a Web monitoring strategy. Most simply, a person or group of people can manually check various aspects of the Web site on a periodic basis. Self-monitoring is better than relying on visitors to do the monitoring. However, people can forget, and they probably will not be around 24 hours a day. The results of manual monitoring are rarely recorded in a form that permits historical and quantitative analysis. Information gathered by hand also does not generally get broadly disseminated, so the status of the site is only known by a few people. Writing monitoring scripts and programs that are run periodically lets the machines do the tedious work, and allows for more reliable monitoring. The process of writing, debugging, and maintaining (especially if the author of the scripts eventually leaves the organization) a set of monitoring scripts or programs can take a Web administrator’s time away from other crucial matters. Home-grown tools generally have no documentation and cryptic user interfaces, which limit access to these tools and their data to a select technological few. Considering the cost of downtime of critical public and internal Web servers, and the cost of implementing and maintaining in-house monitoring scripts, the investment in commercially supported Web monitoring tools is well-justified. Commercial monitoring solutions should be simple to install and configure, and should have user interfaces that are accessible to nontechnical as well as technical people. Although a product should be turnkey, the ability to easily extend the monitoring software to accommodate a site’s specific monitoring needs can be invaluable. THE SITESCOPE/SITESEER SOLUTION The SiteScope/SiteSeer family of products is designed to fit the complete monitoring requirements for Web servers. 509

SYSTEM AND NETWORK MANAGEMENT SiteScope is complete Web monitoring software that is installed on the Web server. Monitors are provided for all the major components of a Web site. When problems occur, alerts notify the administrator or automatically fix the problems. Graphs and reports are generated that summarize the historical data. As part of installation, a default set of monitors is automatically created. A Web-based user interface is used to view the current status or customize the configuration. Additional customization can be performed by adding scripts and using a Custom Monitor API. SiteSeer is a remote monitoring service that provides the same monitoring, alerting, and reporting features of SiteScope, but from a remote location. It provides critical information about the performance and availability of a Web site from an end user’s point of view. Together, SiteScope and SiteSeer provide a complete Web server monitoring solution needed to keep critical Web servers running 24 hours a day, seven days a week. © 1999 WRQ, Inc.

510

Chapter 43

Database Management and the Internet: Developments and Challenges Bhavani Thuraisingham

DURING

RECENT MONTHS THERE HAS BEEN AN INCREASING DEMAND TO

access the data stored in different databases through the Internet. The databases may be relational databases, object-oriented databases, or multimedia databases containing unstructured and semistructured data such as text, voice, video, and images. These databases are often heterogeneous in nature. Heterogeneity exists with respect to data structures, data types, semantic meanings, data models, architectures, query processing strategies, and transaction management techniques. Many vendors of database management systems (DBMSs) are enhancing their products with capabilities for Internet access. Exhibit 43-1 illustrates how clients access multiple databases through the Internet. Special Internet protocols are needed for such access. The goal is to provide seamless access to the heterogeneous databases. Although much progress has been made with respect to Internet database access, there is still room for improvement. For example, database management system (DBMS) functions such as data modeling, query processing, and transaction management are impacted by the Internet. The algorithms for query processing and transactions management may have to be modified to reflect database access through the Internet. For example, the cost models for the query algorithms may have to include the price of accessing servers on the Internet. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

511

SYSTEM AND NETWORK MANAGEMENT

Exhibit 43-1. Internet-based client/server communication.

Furthermore, distributed object management technologies need to be examined for heterogeneous database integration through the Internet. This chapter discusses the impact of the Internet on various DBMS functions. DBMS FUNCTIONS Key DBMS functions include data representation, query management, transaction management, storage management, security management, integrity management, and metadata management. For an Internet database, functions such as browsing and filtering also have to be managed. Data Representation Various data representation schemes have been proposed for text databases, including Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML), and office document architecture (ODA). However, a considerable amount of data will also be stored in structured (i.e., relational and object-oriented) databases. Appropriate data models for representing structured as well as unstructured databases include integrated object-oriented, relational, and hypertext-based data models for Internet database management. Currently, there are no agreed-on standard data models; appropriate mappings between the standards and the heterogeneous data models used by the databases must also be developed. Query Management Query management involves developing language and processing techniques. The query language depends to a great extent on the data model used. 512

Database Management and the Internet: Developments and Challenges Languages based on SQL are popular for relational as well as nonrelational database systems. For example, object-oriented DBMSs use variations of SQL for database access. An appropriate SQL-based language needs to be developed for accessing structured and unstructured databases. SQL extensions are being examined to handle different data types. Once a standard language has been developed, mappings between the standard language and the languages used by the individual databases must be examined. For efficient query processing, modifications to current algorithms for distributed and heterogeneous databases should be considered. For example, current cost models focus mainly on the amount of data transferred between the different sites. Database administrators have many issues to consider, such as: • Are such cost models still valid for Internet databases? Are there other factors that need to be considered in query processing? • Will the cost of accessing remote database servers over the Internet have an impact on the query algorithms? • What are the relationships between global and local optimization strategies? What are parameters that are common to both the global and local cost models? Because of the information explosion caused by the Internet, various technologies such as agents and mediators are being considered for locating the data sources, mediating between the different data sources, fusing the data, and giving responses to the user. Browsing and Filtering Although many traditional DBMSs do not support browsing, such systems on the Internet need to provide this capability. One of the main uses of the Internet is browsing through and accessing large amounts of information in a short time. Therefore, to efficiently access the database, the DBMS must be augmented by a browser. Numerous browsing tools are available for the Internet; however, they must be integrated with the DBMS. Closely related to browsing is the filtering technique. With the Internet, the user can become overloaded with information. This means various filters have to be integrated with the browsers and the DBMSs so that unnecessary information is filtered out and users get only the information they want. Transaction Management Transaction management, an integral part of DBMSs, involves concurrency control and recovery. New kinds of transactions are taking place on the Internet, such as making a purchase. In some cases, multiple users may want to purchase the same item and may bid on it. In such a situation, there 513

SYSTEM AND NETWORK MANAGEMENT should be a waiting period before the item is locked. The item is then sold to the highest bidder. The previous example illustrates the need for flexible transaction models. The ability to perform long-duration transactions and transaction models for workflow management may also be valuable. Serializability conditions may be helpful for concurrency control. Otherwise, it may not be possible to ensure that all the data items accurately reflect the realworld values. Transaction management also requires consideration of recovery management as well as fine-grained versus coarse-grained locking issues. Storage Management For appropriate representation strategies for storing multimedia data, efficient access methods and index strategies are critical. A user should be able to index based on content and context. Research on extensions to various strategies such as B-trees is one possible solution. Internet database management is such a challenge because of the large amount of information and user requirements for quick access. This is why development of methods for integrating database systems with mass storage systems is so critical. Security Management Security is vital to Internet database management; however, the policies must be flexible. With the increasing number of databases, negotiation between the different administrators becomes important. The developers of security for Internet applications are faced with many questions, such as: • Is there a need for one or more global Internet security administrators? That is, is there a group of one or more individuals responsible for overall database security on the Internet? • Is it at all possible to designate a group of individuals to be in charge of global security when there may be many different systems on the Internet? • If there are such global administrators, what are their roles? What are the security features that they enforce? • What are the relationships between global administrators and local database administrators? That is, should the global and local administrators negotiate to determine their functions, or is there someone overseeing their actions? If there is someone overseeing the local and global administrators’ actions, then there must be a supergroup that has ultimate authority for security. If there are no global administrators, which may be the case because it would be very difficult to enforce security policies across different systems, 514

Database Management and the Internet: Developments and Challenges then a type of negotiation needs to be established between the systems administrators of the individual systems on the Internet. Other security issues include enforcing appropriate authorization and access control mechanisms. The implementation of these mechanisms depends on the standard data models and languages used. Extensions to the query language are necessary for enforcement of security constraints, including: • mechanisms for identifying and authenticating users • laws on electronic copyright protection • methods for detecting plagiarism There are several additional concerns if multi-level security is needed. For example, the trusted computing base must be determined, as well as how much of the Internet software should be trusted. Integrity Management Concurrency control and recovery techniques maintain the integrity of the data in the databases. Integrity issues revolve around data quality. With Internet database access, data could come from many different sources. Users need information concerning the accuracy of the source. Appropriate tagging techniques can be enforced and integrity constraint checking techniques used for Internet database access. Metadata Management Metadata describes the data in the database, including schema information. Metadata management is critical to other database functions. Metadata may include not only information about the data in the databases, but also information about the tools, resources, and policies and procedures. Metadata may be used to navigate through the Internet. In addition, information such as transactions history, access patterns, and access control may be part of the metadata. Standards and models are key, in addition to techniques for querying and updating. Interoperability The heterogeneous databases on the Internet must be able to interoperate. Distributed object technology can be used for interoperability. For example, an object request broker (ORB) based on the Object Management Group’s (OMG) specifications can be implemented for interoperation through the Internet (see Exhibit 43-2). The major challenge is to develop appropriate interfaces between the ORB and the Internet. The OMG’s Internet Special Interest Group is focusing on these issues. Work is also being done on integrating OMG’s CORBA, Internet, and Javasoft’s Java technologies. 515

SYSTEM AND NETWORK MANAGEMENT

Client

Server

ORB

Internet

Exhibit 43-2. Internet-ORB interoperability.

Java. As a programming language that can be used to develop systems as well as applications for the Internet, Java is showing a lot of promise for Internet database access. One of the major developments for data access is the standard called Java Database Connectivity (JDBC). Simply stated, database calls could be embedded in a Java application program so that databases may be accessed through these calls. JDBC may be built on other standard protocols. Many DBMS vendors are providing support for JDBC.

CONCLUSION This chapter has examined database management functions and discussed the possible impact of the Internet. There is a need for integrating structured and unstructured databases. Special query optimization techniques also need to be investigated and database management systems have to be integrated with browsers. Information must be filtered so that users get only the relevant information — for this reason, flexible transaction models are needed for Internet database management. Content and context-based indexing and special access methods for multimedia data should be examined. Integrating database systems with mass storage systems will become important to handling petabyte-size data stores. Support for flexible security policies and techniques for copyright protection and detecting plagiarism are also important. Data quality issues need further investigation. There are many issues related to metadata. For example, database administrators are still trying to determine exactly what it is, who owns it, and whether it is realistic to have global managers responsible for the metadata that is not specific to any system or server. Interoperability based on distributed object technology and Java is becoming increasingly popular. However, there is still a lot of work to be done 516

Database Management and the Internet: Developments and Challenges in these areas to provide successful Internet database access. DBMS vendors are moving in the right direction, and the research community is also becoming very active. Once solutions are found to address some of the issues discussed here, users can expect efficient and secure access to the multitude of databases scattered across the various sites around the world. Bibliography Java White Paper, Javasoft 1996, URL: http://java.sun.com:80/doc/language_environment/ Proceedings of the First IEEE Metadata Conference (Silver Spring MD: April 1996.) Thuraisingham, B., Database Management and the Internet, Object Management Group’s Internet Special Interest Group Meeting Proceedings, (Washington, D.C.: June 1996.) Thuraisingham, B., Data Management Systems Evolution and Interoperation (Boca Raton, FL: CRC Press, 1997.)

517

Chapter 44

OLAP Agents: Monitoring the Data Warehouse Dave King

THE WEB HAS WROUGHT AN INFORMATION OVERLOAD — IT IS ESTIMATED to contain 90 million pages and is growing at the rate of 170,000 pages daily. In terms of bytes of data, the size and growth of the Web actually pales in comparison to the size and growth of some individual data warehouses. Assuming 80 characters per line and 66 lines per page, the total number of bytes on the Web hovers around one-half terabyte. Yet this is only one sixth the size of MCI Telecommunications Inc.’s data warehouse, which contains three terabytes of data on the spending patterns and product usage of 100 million customers. To put this in perspective, if warehouseMCI (MCI’s internal name for its warehouse) were converted to book form, it would contain about 280 million double-sided pages and reach the height of approximately 95,000 feet. MCI is not alone. As enterprises redirect their focus from products to customers — their care, retention, discovery, and tracking — there is increasing emphasis on collecting and analyzing more and more detailed data. Although most data warehouses start out small (i.e., less than 25 gigabytes), few remain that way. Based on estimates from the Aberdeen Group, the “average data warehouse can be expected to grow six- to sevenfold every 18 months.” According to Randy Mott, Wal-Mart’s chief information officer, Wal-Mart’s warehouse is expected to quintuple in size over the next few years. The petabyte (1000 terabytes) warehouse looms on the horizon. DELEGATE, DO NOT NAVIGATE As far back as 1986, Alan Kay, one of the inventors of Windows-based computing, recognized the problems associated with “point-and-click” navigation of very large data repositories and the potential utility of “agent-based” systems for addressing issues of information overload. 0-8493-0835-6/00/$0.00+$.50 © 2000 by CRC Press LLC

519

SYSTEM AND NETWORK MANAGEMENT More recently, Nicholas Negroponte, director of MIT’s Media Lab, echoed the same theme in his acclaimed book Being Digital. Negroponte said: “Future human computer interface will be rooted in delegation, not the vernacular of direct manipulation — pull-down, pop-up, click — and mouse interfaces.” “Ease-of-use” has been such a compelling goal that one sometimes forgets that many people do not want to use the machine at all. They want to get something done. What we call “agent-based interfaces” will emerge as the dominant means by which computers and people talk with one another. Many users of the Web have taken Kay’s and Negroponte’s advice to heart. Even skilled users of the Web recognize that it is virtually impossible to locate information on the Web without the aid of a search site such as Yahoo! or AltaVista. Similarly, it is impractical to keep abreast of the Web’s explosive content without some form of automated assistance — personalized news services such as NewsPage Direct from Individual, Inc., push technologies like PointCast Network, Internet agents like Firefly Passport from Firefly Networks, Inc., and Internet robots like NetAttache Pro from CNET Direct, Inc. Much of this automated assistance is designed to filter content according to the user’s stated interests and only notify the user when something of interest occurs. In contrast, most warehouse users still rely on point-and-click queries or online analytical processing (OLAP) tools to manually navigate through the data warehouse in search of exceptions, anomalies, or other notable patterns. Although data browsing and investigation are necessary components of analysis, the task of manual discovery can be tedious, time-consuming, error-prone, and often physically impossible without focusing on some narrower aspect of the data. Automated Sentinels Even when the warehouse is partitioned into smaller, subject-oriented data marts, the amount of data to be analyzed can be enormous. In the case of warehouseMCI, end users are not permitted to query the warehouse. Instead, they are given access to three data marts. Each data mart can consist of more than 80 million rows of aggregate data and information on 140 customer dimensions. A little extrapolation suggests that the fact tables in MCI’s data marts can contain more than 11 billion cells. The problem is exacerbated because the data marts are updated biweekly, a task that takes between 30 and 70 hours to complete. How is it possible to keep up with vast quantities of dynamically changing warehouse data? It cannot be done manually because the risk of ignoring or overlooking problems and opportunities is too great. Taking a lesson from Web users, the task can be delegated to a group of automated sentinels 520

OLAP Agents: Monitoring the Data Warehouse whose main role is to monitor the data warehouse or data mart for patterns of interest and then notify the end user when those patterns occur. Those sentinels go by a variety of names, although “software agent” seems to be the preferred label. SOFTWARE AGENTS DEFINED Agents come in a variety of forms and differ in a number of key features. It is important to understand which features are critical for dealing with the problem of data warehouse overload and for serving various classes of end users. A software agent is an independent process, program, or object (in the object-oriented sense) that: • operates in the background without human intervention • supports conditional pattern matching (usually in the form of if-then rules) • focuses on a single or small set of tasks There is a certain amount of intelligence, mobility, and agency that a process, program, or object must possess to qualify as a software agent. An agent is expected to have enough intelligence to: • process user preferences, which are stated in the form of logical rules, at minimum • learn and adapt to the user’s actions and to the resources in the environment, at maximum The agent must have enough agency to: • run as an asynchronous process, at minimum • collaborate or negotiate with other agents, at maximum The agent must have enough mobility to: • reside on a single client or server, at minimum • allow objects to travel from machine to machine carrying accumulated state data, at maximum Most of the research on software agents focuses on the high end of the continuum — that is, processes that learn, collaborate, and travel from machine to machine. In practice, most agents are at the low end of the continuum — that is, they asynchronously process data on a single machine in search of patterns that match user-defined rules. OLAP AGENTS Over the past few years, a handful of OLAP and relational OLAP (ROLAP) vendors have begun offering software agents as an integral part of their 521

SYSTEM AND NETWORK MANAGEMENT product lines or suites. Seagate Software, Information Advantage, Inc., MicroStrategy, Inc., SAS Institute, Planning Sciences, and Comshare, Inc. are among the handful. These OLAP agents are triggered or scheduled processes that run on a client or server and use detection rules to automatically monitor, filter, or query a large or frequently changing data set (i.e., a warehouse or data mart) searching for patterns defined by those rules and informing interested users or other processes when the patterns are detected. Agents of this sort have also been called “software filtering agents,” “watcher agents,” and, more recently, “notification systems.” The results produced by these pattern-matching activities are usually called “alerts” or “notifications.” The detection rules employed by the various ROLAP agents run the gamut from simple exceptions, to standard query language-like queries, to complex exceptions based on comparisons of actual data with projected timeseries forecasts, to interrelated combinations of rules that act in sequence or concert. Although complex rules are often supported, the vast majority of work being done by OLAP agents involves simple logical comparisons. In a typical scenario, whenever a data warehouse or data mart is updated, one or more OLAP agents are used to rifle through the updated data searching for under- or overperforming products, locations, or salespeople. The under- or overperforming entities are collected together in lists or reports and then distributed to interested end users (or other application processes). In other words, OLAP agents are often used to perform repetitive tasks involving simple arithmetic or logical comparisons that could be performed by a person, if the person had the time or inclination to do so. Even if the person had the time, there is no assurance that the person could perform it with the same accuracy as the agent, regardless of how simple the logic was. If an individual were asked to check a couple of million cells in an OLAP data mart to enumerate the cells with values over ten, he or she could certainly do so, although the speed and accuracy with which the individual accomplished the task would not rival the performance of a software agent assigned the same task. Data Validation Another straightforward task that OLAP agents are being asked to perform is data validation. Unlike relational databases, multi-dimensional OLAP databases lack built-in validation facilities. Agents can be assigned the task of watching specific cells in the data mart or data warehouse to ensure that required values exist, or that entered values fall within expected limits. For example, in a planning or budgeting application, agents could be assigned the task of ensuring that various entries have been submitted according to schedule. If they have not been submitted, the parties 522

OLAP Agents: Monitoring the Data Warehouse responsible for the entries can be notified. Similarly, agents can be assigned the role of detecting illegal entries for these applications. Again, offending parties can be notified. AGENT-BASED SYSTEMS A number of enterprises recognize the value of agent-based systems and have stated intentions of incorporating them as soon as their warehouse or data mart is complete. Over time, these agent-based systems are placed on the back burner, because the warehouse or data mart is under perennial construction. Agent-based systems offer a fundamentally different way to manage and participate in the business. Agents support exception-based management, which can substantially reduce the number of reports — paper and electronic — that need to be generated, thus allowing managers to cut through the glut of information and focus on issues that are more important to them. If an enterprise subscribes to this belief, it needs to incorporate agent-based systems, components, or processes early in the deployment phase of the warehouse or data mart, not at the end. The Agent Engine Belongs on an Application Server Given the size of the average data warehouse and data mart, the processes that evaluate the rules against these data sources need to run on a server-class machine. The comparative benefits of today’s three-tier client/server architectures versus yesterday’s two-tier architectures are welldocumented. By implication, the optimal place to locate an OLAP agent is on an application server situated in the middle of the three tiers. This placement also allows the agent to be applied to multiple data sources and pinpoints some of the limitations associated with using database triggers as agents. Personalized Rules and Results One assumption that vendor companies had long made but that is changing is that some groups would want to share rules and that many executives and managers would want an administrator or application builder to create rules for them. This may have been true at the end of the executive information system (EIS) era, but it is not true in the Web era. Most users want the ability to create their own personalized rules, to schedule the running of these rules, and to have the results generated by the OLAP agent narrowcast specifically to them. The Rules of Rule Building Because users possess a wide variety of skills, the process of rule building needs to be as simple yet as powerful as possible. First, rule building 523

SYSTEM AND NETWORK MANAGEMENT should be guided by “wizards,” which are step-by-step forms that guide the user through the rule construction process. Second, rule building should be available as the end user is browsing and navigating the data warehouse or data mart. It is difficult for users to establish a set of rules unless they have a general feel for the distribution of the data. Third, users need a way to immediately test and fine-tune the output from the rules to ensure that the resulting alerts are not as detailed as the original data. Finally, the rules should support “time” and “hierarchical” intelligence. For example, a user might want to create a rule for tracking expense overruns for the “current period,” not for a specific time period like February. Similarly, a user might want to monitor inventory for all the products under a particular brand without having to specify every single product. Without time and hierarchical intelligence, rules will either proliferate or have to be frequently restated. Viewing the Results in Context Just as it is difficult to create rules in isolation, it is difficult to interpret alerts or notifications in isolation. Is the alert really that exceptional when compared to similar entities? Can the surrounding data explain or help interpret the anomaly? Does this alert signify a general trend? To answer these and other questions, users need the option of immediately accessing and viewing the surrounding data from which the alert came. Also, with immediate access, users can establish additional rules as they explore the alert’s surroundings. Multiple Distribution Mechanisms Initial design for some products, such as Comshare’s Detect and Alert, relied on an e-mail backbone for delivery of alerts. For example, Comshare relied on Microsoft Mail (MAPI) and cc:Mail (VIM). But the penetration of these mail systems was not as fast or as widespread as predicted. Although these are among the most popular e-mail systems, enterprises and users require a range of choices for distributing the results produced by an agent. Besides e-mail, some of the alternatives for distributing results include the Internet, faxes, personal digital assistants, telephones, data warehouses, a separate database, or directly to the OLAP browser or query tool. In this way, even mobile users can have 24-hour global access to the agent output. Open Systems For the most part, OLAP agents output their results in the form of alerts that are delivered to the user’s desktop. Increasingly, decision support 524

OLAP Agents: Monitoring the Data Warehouse applications, like merchandise planning in the retail world, are being linked with various operational processes like inventory distribution. Because of their ability to identify problems or opportunities, OLAP agents have the potential to serve as the link between these analytical and operational systems. CONCLUSION Several years ago, most discussions about agent-based systems either began or ended with the phrase “in the future . . .” The phrase implies that existing agents are simply “limited editions” of coming generations. The future for agent-based systems has just about arrived, and it is found on the Web. The Web has become an experimental playground for practical software agents of all sorts. Increasingly, data warehouses and data marts are being accessed and linked through intranets and the Internet. This linkage exposes these data sources to a much larger audience of end users. Although most of these users lack the skills of a seasoned data analyst, many are still experienced Web users who have come to rely on the search and agent facilities available at virtually every major Web site. They have also come to expect the same sorts of facilities for the data warehouse and data marts on the Web. Autonomous agents are really objects with properties and methods. For the most part, agents have remained stationary because of the difficulty of creating objects that can execute on different platforms. Java and ActiveX, or more specifically the Object Management Group’s common object request broker architecture (CORBA) specification and Microsoft’s Distributed Component Object Model (DCOM), are rapidly eliminating this barrier. Mobile agents that can traverse the Web, moving from warehouse to warehouse or data mart to data mart in search of anomalies, exceptions, and patterns of interest appear to be on the horizon.

525

Chapter 45

Enterprise Data Management with CIM and XML Paul Korzeniowski

ONE

REASON WHY COMPANIES ADOPTED DATABASE MANAGEMENT

systems (DBMSs) is that these systems helped to integrate the autonomous nature of corporate information. Previously, information was stored by application, which added a lot of processing overhead and increased the chances of erroneous entries being generated. DBMSs enabled companies to store information in a central place so applications viewed information collectively rather than autonomously. A similar transformation is about to take place in the enterprise management space. Because of the rapid acceptance of network computing and an increasing reliance on the Internet, networks have become important to organizations. Not only do employees rely on them to exchange information, but customers and suppliers also need them to place orders or ship goods. As networks have become vital to daily operations, so has the desire to ensure that they remain up and running. Because it would be impossible for a technician to examine each component on a worldwide corporate network, management tools have emerged that automate the process. Unfortunately, they do not offer organizations as much functionality as desired. A large part of the problem stems from the rapid expansion and growing complexity of corporate networks. Even in a simple dial-up network connection, performance problems could stem from a variety of locations: desktop application, a communications package, a modem, a wide area network (WAN) link, the receiving system’s modem, a remote access concentrator, a corporate LAN, a directory server, a backbone switch, a DBMS server, or a Web application. Suppliers have delivered tools, called element management packages, that test individual components, such as a DBMS. Corporations desire 527

SYSTEM AND NETWORK MANAGEMENT tools that will examine all components and determine which one is slowing down the connection. But suppliers have not been able to fulfill this desire because their tools cannot consolidate the information coming from the element management packages. This shortcoming has not stemmed from a lack of effort. Vendors, such as Computer Associates International, Inc., Hewlett-Packard, and IBM, have pumped millions of dollars into the development of enterprise management frameworks that would be able to gather data from element management packages. Their tools included open application programming interfaces (APIs) so third parties could send management information to central consoles for processing. In theory, the enterprise management tools would solve integration issues; but in reality, this has seldom been the case. APIs are complex and difficult to use. Third parties were not terribly interested in helping framework suppliers promote their wares and instead focused on adding new features to their packages. So, the onus fell on users to improve upon the rudimentary integration between element management and enterprise management systems. To complete the work, corporations needed skilled technicians; thus, the demand — along with salaries — for such professionals grew. Corporations invested a great deal of time and effort in rolling out enterprise management systems, but many failed to deliver their promised levels of integration. Standards would have helped the process. Starting in the mid-1980s, vendors forged several such initiatives. There was some progress: the Simple Network Management Protocol (SNMP) provided a common way of moving management information from a device to an element management package. Unfortunately, no easy way to ship information from several element management packages to an enterprise management console emerged. Consequently, technicians were left tinkering with a hodgepodge of different element management tools. So now, corporations desire more from their management systems: more integration among applications, more ease in navigating from one element management application to a second, and more help in determining what may be causing a performance slowdown. THE WEB EMERGES AS NETWORK MANAGEMENT PANACEA Soon, they may get it. Just as the Web dramatically altered the way companies build daily business applications, it is changing the way application, network equipment, DBMS, and systems vendors design their management applications. Rather than continue to be locked into proprietary application programming interfaces (APIs) that hinder interoperability and increase development costs, suppliers are moving to open, Web-based systems. 528

Enterprise Data Management with CIM and XML World Wide Web technology has emerged as the dominant new development environment for a number of reasons. Web software is built on open standards that can significantly reduce development costs. Using standard Web browsers to develop GUIs eliminates the bottlenecks inherent in traditional cross-platform application development and reduces engineering requirements. Web software tends to be less expensive than traditional commercial products. Unlike previous network management initiatives, the move to Webbased management tools is in synch with customers’ desires. Corporations understand that browsers offer an inexpensive, easy-to-use alternative to proprietary and command-line user interfaces and are now demanding devices that can be accessed, monitored, and controlled by them. Soon, companies will no longer have to hire expensive specialists who understand difficult network management programs. Instead, they can choose from the large — and growing every day — pool of Web programmers. Aware of customer desires, suppliers are embedding Web server software in their products’ firmware, a move that gives customers Web management capabilities without the high cost of traditional network management systems. Technicians can monitor, control, and configure products; obtain status and statistical data; and upload firmware updates and configuration files with standard Web browsers. They can perform these tasks via a wide range of Web-enabled devices: laptop computers, personal digital assistants, cell phones, and pagers. PUTTING THE PIECES IN PLACE While the Web has the potential to solve outstanding enterprise management issues, not all of the pieces necessary are in place yet. The first set of Web-based management applications offered a browser-based view of static, simple, and proprietary pages. While this is a good initial step, it still does not fully address the problem of information integration. To take on these challenges, suppliers will have to develop standards that will mask all data differences. Standards are a place where network management suppliers have historically come up short. All of the groups formed to ease management chores have experienced varying degrees of success before splintering with one notable exception: the Desktop Management Task Force (DMTF). Founded in 1992, this consortium’s first goal was to develop specifications for the collection of management information from desktop PCs. At the time, central technicians could not query a remote system and learn fundamental issues, such as how much RAM was in the machine and what applications it was running. The consortium developed the Desktop Management Interface (DMI) specification, which provides hardware and software management information. 529

SYSTEM AND NETWORK MANAGEMENT As the DMI specification started to gain acceptance, the Internet was beginning to become the computer industry’s focal point. Hardware, software, and network equipment suppliers viewed it as a potential elixir to their long-standing management problems. In the fall of 1996, industry heavyweights BMC Software, Inc., Cisco Systems, Inc., Compaq Computer Corp., and Microsoft, Inc. outlined plans for the Web Based Enterprise Management (WBEM) specifications, which would leverage Internet standards and technology to solve enterprise management issues. The companies turned development work over to the DMTF, and WBEM became the umbrella under which the DMTF will fit its current and future specifications. The goal of the WBEM initiative is to outline standards based on Internet technology that provide for interoperable management of devices in an enterprise. The ultimate objective is to provide customers with the ability to manage all systems, regardless of their instrumentation type, using common standards. THE MISSING ITEMS: CIM AND XML After taking on WBEM development, the DMTF set out to develop the Common Information Model (CIM), an object-oriented information model that provides a conceptual framework within which any management data can be modeled. The model is not bound to a particular implementation and allows for the interchange of management information between management systems and applications, which can be either agent-to-manager or manager-to-manager. In a CIM-compliant world, one can build applications using management data from a variety of sources and different management systems. The specification allows management data to be collected, stored, and analyzed using a common format while allowing vendors to add proprietary extensions for value-added functions. CIM includes two parts: the CIM Specification and the CIM Schema. The CIM Specification describes the language, naming, Meta Schema, and mapping techniques to other management models such as SNMP MIBs. The Meta Schema defines the terms used to express the model and their usage and semantics. CIM offers a richer way of describing managed resources; originally developed for systems, it has been extended for describing network infrastructure, devices, and applications. CIM was an excellent foundation on which to build standards that solve management data interchange problems. However, vendors have been using CIM as a data model, but retaining their own proprietary encoding and transport mechanisms for exchanging data between applications. This has limited interoperability and forced users to standardize on a single vendor’s management software. 530

Enterprise Data Management with CIM and XML The DMTF had a couple of options for tackling data exchange problems. One possibility would have been to create a new application development standard. However, this approach would have continued to wedge network management issues into a narrow niche and drive up personnel and programming costs. Instead, the group decided to adopt the Extensible Markup Language (XML). It is a metalanguage that describes information about information and describes how data is formatted and exchanged between servers and clients over an IP network. XML is the more-powerful big brother of the widely accepted HyperText Markup Language (HTML). XML is similar in concept to HTML; but whereas HTML is used to convey graphical information about a document, XML is designed to add structure and convey information about documents and data. XML provides more programming tags than HTML and can therefore be used to format and structure information more precisely. XML provides a way of identifying structured management information exchanges so applications can trade CIM data. With XML, a programmer can specify details about elements through Document Type Definitions that provide a way to pass information between different vendors’ products or send it directly to a Web browser. XML provides an application with access to diverse data sources and the ability to manipulate them many times without a trip back to a database. One plus is that XML is emerging as a de facto data manipulation standard for all Web application development. In February 1998, after roughly a year and a half of evaluations, the World Wide Web Consortium (W3C) released XML 1.0 as an official recommendation. The XML Working Group defined a flexible language that is useful for representing a variety of data types on the Web. Support for the specification has come from all of the major database management system suppliers and Microsoft and Netscape, which are adding XML compliance to their browsers. In October 1998, the DMTF announced its first version of XML and support came from a broad range of suppliers, including Cisco; Computer Associates International, Inc.; Microsoft; and Tivoli Systems, Inc. THE FUTURE BECOMES CLEARER Coupled with CIM, XML offers users the first realistic attempt at integrating management data and linking heterogeneous management systems and tools. The standards should gain widespread acceptance because they offer so many benefits to network equipment suppliers and their customers.

531

SYSTEM AND NETWORK MANAGEMENT For suppliers, CIM and XML will ease element and enterprise management application development. The specifications work with a wide range of hardware, software, and applications and can scale from small to large networks. Rather than work with proprietary interfaces, applications will rely on common standards. Instead of porting software to a range of APIs, suppliers will be able to write software once and connect it to any compliant element or enterprise management system. Ultimately, suppliers will embed XML in a new generation of smart devices that will be simpler to configure and easier to manage than current devices because they are Web based. Customers will be happy. The move to standards will provide them with a simple, standards-based physical and logical interface to management data. The standards are flexible enough to cover all network management requirements: physical management, billing, and root cause analysis. So, once implemented, the standards will enable them to examine end-to-end network performance rather than continue to work in a piecemeal fashion. HOW THE WEB WILL SIMPLIFY ENTERPRISE MANAGEMENT The move to CIM and XML will help companies identify network problems faster and more easily. Currently, network managers have to bounce from one element management to another to pinpoint a troublespot. With the growth of networks, technicians may have to manipulate a dozen or more management applications. CIM will enable technicians to systematically test all potential troublespots and identify the faulty device; and CIM — combined with the Web — makes this possible using only one interface: a Web browser. For example, the executive vice president of marketing, who works out of one of the firm’s remote offices, calls the help desk regarding problems accessing an Intranet application that lets employees place orders for computer equipment. The help-desk technician must quickly examine each component along the link (the user’s browser, his PC, his network connection, the local switch, the local router, the central remote access concentrator, the data center switch, the Web server’s network connection, the server, the DBMS, and the application), pinpoint the malfunctioning equipment, and take the steps necessary to improve the response time. With CIM, an enterprise management application will start at the lowest layer of the networking model and work its way up until the problem is identified — a process called root cause analysis. First, the management tool will check the physical network connection (the local switch, the local router, the central office remote access concentrator, the data center switch) by sending a packet along the line. Next, the management tool will examine the network layer (the user’s network connection, the Web server’s connection) and determine whether or not there is a protocol problem. Then, the management tool will look at the server 532

Enterprise Data Management with CIM and XML and determine how quickly it is processing information. The manager can then move up to the DBMS and examine how quickly it is processing information. Last, the management tool will examine the application layer (the browser, the intranet application) and determine if it is hung up. Root cause analysis offers companies two benefits. First, training requirements drop since a technician only needs to know how to operate a browser rather than a series of proprietary user interfaces. Second, suppliers can build more sophisticated management applications, ones that examine problems and recommend solutions on an end-to-end basis rather than in piecemeal fashion. Increasingly, companies want to examine system and network performance on an end-to-end basis rather than in piecemeal fashion. THE IMPACT OF CIM AND XML ON DBMS SUPPLIERS When a user calls the help desk to report a response time problem, a technician would like to enter a few commands, quickly discover that the DBMS is having problems processing requests, drill down to examine why the problem is arising, and make any necessary changes. CIM and XML compliance would make such compatibilities possible. To move toward that goal requires that suppliers incorporate support for the emerging standards in their DBMS management tools. Currently, these tools rely mainly on SNMP to gather and transport management information. Moving to CIM and XML offers DBMS vendors a couple of benefits. First, these standards are more flexible and better able to gather DBMS performance data than SNMP, which was designed to oversee network equipment. Second, they are more in line with the customers’ desire to integrate all management data. Because of the benefits, DBMS management suppliers are starting to line up in support of XML and CIM. BMC Software and Microsoft have been two of the key supporters of the WBEM initiative and have stated plans to back the emerging standards; and DBMS suppliers vendors Informix, Oracle, and Sybase see XML as an aid in easing customer application development as well as systems management. CONCLUSION The move to the new standards will take time. The enterprise management space has been evolving for more than 15 years, so there is now a huge base of installed management tools. Corporations will only be able to justify the expensive and often difficult task of moving to new management tools in select cases. Consequently, the migration to CIM and XML will be expected, but three to five years may pass before it is widely adopted. While one can debate the timeline, there seems to be a consensus that movement to CIM and XML will occur and end-to-end management chores will eventually become simpler. 533

SYSTEM AND NETWORK MANAGEMENT Notes 1. CIM, XML Web sites: www.dmtf.org 2. Vendors supporting the standard: www.bmc.com www.cisco.com www.compaq.com www.microsoft.com www.tivoli.com

534

Chapter 46

Maximizing Mainframe-based WAN Resources Gale Persil

IF YOU ARE READING THIS CHAPTER, THEN IT IS NOT NECESSARY TO TELL you that the IP revolution is totally transforming the host-centric SNA world. As often quoted, IDC predicted that by the year 2000, 96 percent of MVS installations would be running some sort of IP stack on the mainframe. Like most organizations, one has likely already dabbled in IP by providing access to a remote office, or installing an MVS-based Web server for a small intranet, or is already depending on IP network traffic to service critical business applications.1 The network likely contains some of the complex aspects shown in Exhibit 46-1. But business is not standing still. According to IDC,2 over 60 percent of mainframe organizations are looking to build or extend their customer support services to remote or Web access. This might be as simple as providing access to a problem database to remote offices or a help desk outsourcer, or as sophisticated as providing full customer access to all or part of the information database. Good examples of leaders in this area are the major package shipping vendors such as FedEx and UPS that offer package look-up services via Web access. In close second, some 54 percent of IS organizations are looking to expand the access of enterprise server-based systems to new employees, both local and remote. To accomplish this, many corporations provide remote or local gateways, introducing TN3270 traffic to the network. While desktop-to-application implementations such as this are still very common, the introduction of the MVS-based Web server has become an exciting prospect for many businesses. One U.S. insurance company introduced a local intranet in this fashion to communicate at its local headquarters. Word of its success spread so quickly through the corporation that the CIO

535

SYSTEM AND NETWORK MANAGEMENT

Daily Workload Application Traffic as % Workload Traffic

100% ADSM FTP

80%

HPNSCICS

60%

NFS PEOPLESOFT

40%

SAP SMTPMAIL

20%

WEBSERV20 10 Aug 1998

9 Aug 1998

8 Aug 1998

7 Aug 1998

Exhibit 46-1.

6 Aug 1998

5 Aug 1998

4 Aug 1998

3 Aug 1998

0%

TN3270

Daily workload application traffic.

mandated that this “internal, local tool” be rolled out worldwide in the following 30 days! Technology is moving at a quick pace. But probably more importantly, it is critical for businesses to be able to respond to competitive and market issues by being able to quickly adjust their technology to respond to the challenges. Building and tearing down extranets to work with a corporate partner, absorbing new technologies and systems due to acquisitions and mergers, and providing access to product information via the World Wide Web (WWW) are a few examples of the techniques that businesses are employing to maintain their competitive advantages. And within the network management scope, the big question among network managers is: how am I going to ensure the same levels of service to this new generation of end users as I did with my SNA network? SNA VERSUS TCP/IP NETWORKS The task ahead is a bit like being an air traffic controller at a major airport — all sizes and priorities of planes are scheduled to land at the airport, and the job is to determine who gets to land and who circles around using up fuel until there is a free runway. However, air traffic controllers have several advantages over network administrators. First, as traffic increases, they are usually supplied with sophisticated equipment to perform their duties. 536

Maximizing Mainframe-based WAN Resources Second, although they are about as unpopular as the person allocating network resources, every pilot and civilian knows that no one argues with the decisions of the controller. Managers of network infrastructure and their support staff rarely get the same vote of confidence about their decisions. In a pure SNA environment, there is an entire operating system set up to monitor and adjust traffic traveling across the SNA bandwidth. It is called the network control program, or NCP. This traffic controller sets the rules for traffic coming into the mainframe, and all pilots are expected to follow the rules. However, because traffic usually originates from within their own country (another NCP), protocol violations are rare. With IP, there is also a set of rules. However, this set of rules was developed by a committee and is executed by vendors that are not required to go through any training or certification in order to enter the network. To the analogy, they also might speak various languages. And when a protocol problem arises, the two parties are left to their own devices to work out an agreement. If they cannot, the plane is turned away and likely never seen again. A committee is then formed to evaluate the sad occurrence. Luckily, most vendors who provide an IP solution to the market are hardworking, intelligent, and well-intentioned people who have not only a genuine interest in making their products work, but a genuine need to make them work. Simply put, if the product does not work, no one will buy it. Technology Decisions On the positive side, this type of competitive atmosphere has long been the suitable environment where major advances can be made because even the smallest players can make significant technology contributions, pushing other vendors to follow. Technologically speaking, choosing the right solution for a particular application, regardless of the vendor, is now very possible and desirable. For example, since TN3270 traffic was growing so dramatically at one CPU-constrained life insurance corporation running about 150 MIPs, the decision was made to install the Cisco Channel Interface Processor (CIP) found on the 7500 router (this same functionality on a smaller-capacity version is found on the 7200 Series gateway). This allowed them to shift processing requirements for their 5000 sessions to within the routed network hardware, saving processing cycles within the MVS TCP/IP stack. This meant, however, that the organization now maintains both IBM and Cisco hardware, and needs to apply management tactics that support both vendors. Of course, there are factors other than technology that might make sense in one’s implementation. For example, while having the printing capabilities of Microsoft’s SNA Server might make sense in one instance, and 537

SYSTEM AND NETWORK MANAGEMENT the Web connectivity with low maintenance on the client PC provided by the IBM Communications Server in another, this results in having to negotiate separate maintenance contracts and learn two separate management interfaces. Still, the benefits of being able to choose a solution that closely fits one’s organizational needs should not be ignored. Different Camps Technology is only one of the issues one faces when migrating to a widearea IP network. The political issues can sometimes sabotage success more effectively than any router choice one might make. Merging of the legacy data center with an enterprise network brings together not only different protocols, but often different cultures, disciplines, biases, and management chains. Think about putting an air traffic controller from a structured, standardized location such as London, England, together with a controller from Bogota, Columbia. The function of these two people on a high level is the same, and there has to be a basic agreement of the signs, protocol, and commands they will use because traffic often flies over the continental boundaries. Still, everything from the basic primary language to the complex internal queuing procedures will likely be quite different between the two towers. In any application — system or network deployment — there is always the issue of dealing with the end users or customers and their requirements versus their expectations of the new system. The combination of SNA and IP adds another complexity — the integration of the mainframe and distributed network management camps. Making Purchasing Decisions Overcoming these issues requires a fair amount of patience, training, and political savvy. Keen network managers should: • Evaluate corporate management. Evaluate the corporate management structure supporting the network infrastructure to make sure it is streamlined to make enterprisewide decisions. In this author’s experience, there is no one successful structure, only people who successfully or unsuccessfully work within the various structures. • Involve multiple high-level managers. Spend more time negotiating and getting buy-in from various factions with different needs. It is recommended that this time be spent up front. If this is not done, one will be left with having to choose lowest common denominator solutions. • Streamline management structure. Be cautious to make decisions based on sound business justifications, instead of just choosing the alternative that is attractive to your technical evaluators. Return-oninvestment (ROI) evaluations, whether strictly implemented or satisfied 538

Maximizing Mainframe-based WAN Resources during a Q&A session with the staff who will be using the tool, can be very helpful in this process. • Consider upfront decisions. Decide up front whether to choose a single vendor or best-of-breed orientation. —Single vendor. Select management strategies that provide the depth of functionality required. This does not necessarily mean choosing the same vendor for management software as one did for IP hardware. In fact, the better software management solutions are often found from a non-hardware vendor because hardware vendors tend to be focused on producing efficient devices. Invest in training and cross-training staff in support of this environment. Motivate the help desk staff to learn these tools by positioning them as an opportunity to advance their skills and value to the organization. —Best-of-breed (or multi-vendor). Select management tools that use standard practices such as SNMP and CNM to monitor and report on networkwide status. Make sure these tools interface with strategies within the enterprise such as enterprise management platform (EMP) implementations or help desk standardization. —Do not invest in strategies that will be costly for years to come. It may seem obvious, but given some of the trends happening in IS organizations in the last few years — with senior management looking for the “pot of gold” at the end of the IT rainbow — this is worth stressing. Even if one has highly trained staff capable of developing new ideas in-house — and enjoy it — the next few years especially will require significant resource investment in projects that have nothing to do with day-to-day maintenance of the network. Staff turnover and crisis response are going to be common in data centers, so plan ahead. Any tools or strategies one invests in should be easy to implement, customize, use, support, and modify. Generally, that means using out-of-the-box solutions instead of choosing to implement new ideas in-house. • Complement your strategies. To complement one’s strategies, choose management tools that can provide or integrate with providers of a full range of options. Specific to an installation, this might include multiple protocols such as TCP/IP for MVS and TCP access, IP device vendors such as Cisco, IBM, Bay, and others, and multiple disciplines such as problem reporting, diagnostics, and capacity planning. WHAT DOES PERFORMANCE REALLY MEAN? Building and expanding the network infrastructure is an ongoing exercise. Once the best infrastructure decisions for an organization have been made, one will want to move on to the day-to-day issues of providing good service to the end users. Although bandwidth and its utilization have always been a hot topic in distributed network management circles, it is a 539

SYSTEM AND NETWORK MANAGEMENT fairly new concern for evolving SNA to IP network managers. Why does there not exist the concept of a “bandwidth manager” in SNA networks? And why are SNA network programmers not obsessed with trying to figure out which applications are using their bandwidth? In SNA, bandwidth is essentially dedicated to a single path (or redundant paths) for a single corporation. This makes bandwidth analysis fairly simple: when response time slows down and utilization is shown to be a problem, more bandwidth or a bigger front-end processor (FEP) is required. In a TCP/IP wide area network, however, this is not always the case. With the use of publicly owned transport networks and other shared line configurations, as well as the fact that TCP/IP inherently and dynamically chooses multiple routes depending on current conditions, understanding traffic flow for different applications throughout the network becomes an important issue. The air traffic controller example can be used to show why this is. Say you are a common destination within a small country for which there are two alternate routes to reach you. The number of alternate routes/airports depends on the fact that small airplanes are limited in their flying distance and, of course, will want to fly the most direct route whenever possible. Given this configuration, if the number of planes landing at your site is increasing on a regular basis, it would be good to plot and understand the growth rate so that you could plan when to either expand the facilities at your current location, or build a new location nearby to accommodate the growth. It does not matter where the traffic originated. There are only two routes to you; and when they become congested, you need to take action. Within a TCP/IP network, however, the number of potential routes is expanded significantly. Imagine that you have just evolved from a local airport to one with international access. Now, planning for growth becomes more difficult because you do not have all the plans, schedules, and understanding of international traffic coming into your terminal. You do not know what their popular routes are, and which tend to be late — impacting your runway availability — until you are in the middle of a crunch and trying to accommodate all incoming traffic. If you could track all the information from a single international point, you should be able to detect patterns in growth and delayed arrivals so that you could adjust your runway utilization more effectively. Although this analogy is basic, the same model easily applies to a widearea TCP/IP backbone network. Because there are so many potential alternate routes, it becomes tedious and bandwidth-intensive to try to track the route of individual transactions through the network. Installing software to monitor performance on each and every PC within a network is a significant undertaking in terms of initial investment, as well as ongoing maintenance. Installation testing has to be done by the user or the IS department 540

Maximizing Mainframe-based WAN Resources on every PC. Companies like Microsoft, Intel, and Tivoli now offer remote distribution capabilities to assist with the large task of disseminating new desktop software. Upgrades can generally be performed in the same manner, or specific vendors might offer dissemination from a centralized server on a scheduled basis. Desktop PC solutions, however, often introduce what Gartner3 in its total cost of ownership (TCO) model calls the “futz” factor. Intrusive solutions that use PC processing power to involve sophisticated users or give the users the ability to modify, interact with, or change the options of their system settings, contribute a significant amount to lost productivity at the individual level. Far from reducing downtime, this type of solution can actually reduce the amount of productive time during network uptime. The Network from the Business Perspective The thing that drives network usage is access to particular applications or data. Thus, it is not enough to understand that e-mail constitutes 20 percent of one’s bandwidth. If there is a set of users (or node) accessing one application, the bandwidth method works just fine. But if an e-mail system is accessed from multiple destinations or hosts, or multiple applications from different sites, one needs to understand exactly what the relationship is between a specific destination and all the users accessing those applications. This information will allow one to make intelligent growth decisions instead of holding on to the SNA mentality of “surgically adding more bandwidth.” The most practical approach to this problem is to understand the types of traffic that are flowing in the network from an end-to-end point of view. Since that “end-to-end” term is extremely overused in today’s marketing literature, take a look at what it means. In a wide area network such as depicted in Exhibit 46-1, a comprehensive understanding of the actual usage of the network includes knowledge of traffic flowing into the mainframe, and the applications being accessed within the mainframe boundary — which may or may not be IP based. One indicator of application usage is port activity — because ports are generally dedicated to an application. So, for example, traffic connected to ports 1414-1417 indicates MQSeries activity, while traffic connected to ports 1364 and 1365 would indicate CONNECT:Direct usage. This is how many network management traffic reporters gather specific traffic statistics. When the mainframe is actually the server, it is also important to understand what specific CONNECT:Direct region is being connected to. The multiaddress space, multisystem, and load balancing capabilities of the OS/390 operating system provide a great deal of flexibility in managing traffic that does not involve simply “surgically adding more bandwidth” to solve capacity problems. 541

SYSTEM AND NETWORK MANAGEMENT Many alternate solutions can be implemented that would be both reasonable and sensible from a corporate point of view. Take the case of a leading department store that noticed increased response times during prime working hours. While most of the time adding bandwidth would make sense, a careful analysis of network traffic showed that a particular department — the sales area — was the source of continuous large data transfers. Investigation showed that a popular Web news page was being brought up in users’ Windows startup and left running all day. A corporate policy was instituted that educated users on the damage of using active Web pages as screen savers, and the IS department immediately saw a 30 percent reduction in overall bandwidth utilization, and a 23 percent drop in daily data transfer. Of course, with more bandwidth to handle other transactions, end-user response time for real-time activity benefited. In another case, a mail-order catalog house began to notice response time deteriorating for their online customer support representatives. As a result, sales were beginning to suffer because customers became frustrated by holding on the line while representatives waited for their system to determine whether a particular item was in stock and available to ship. Careful analysis of the number of connections from this destination to the mainframe host showed that finance and administration (F&A) personnel from this site had been recently logging onto the system during the day to obtain customer account information in “real time.” Customer account information was usually updated to a local database once a month via a scheduled CONNECT:Direct transfer so that F&A would have reasonable information to work with. Recently, the F&A department had received numerous complaints from customers who had received late notices after having paid their outstanding invoices. In attempting to be responsive to these complaints, they were running extensive queries against the realtime data to make sure they had the up-to-date information for a particular account. The “bandwidth view” would have suggested upgrading the local gateway to respond to the additional connections; and in truth, this is an option that would resolve this situation. But because there was room in the batch FTP window, the alternative chosen by this account was to update the local F&A customer database on a weekly basis instead of a monthly basis. This reduced the remote access requirements, freeing bandwidth for the online representatives and increasing their response time. In addition to ports, effective network utilization can be achieved by understanding the following information on network usage. • SNA applications (i.e., LUs and tasks) being accessed • the number and type of connections (by port); for example, TN3270, FTP, CICS sockets, etc. 542

Maximizing Mainframe-based WAN Resources • statistics on individual users and how they impact the system; specifically, how many and for how long they are connected, and how much data is being transferred while they are connected • reports on peak time periods, over a period of time; for example, what is the busiest day of the week? busiest week of the year? • given the current traffic load, what is the load and efficiency on the critical IP devices such as routers and hubs? Because of the difficulty in using the basic functionality provided with OS/390 stack implementations — that is, the NETSTAT command — many organizations provide TN3270 access to remote sites, but have absolutely no idea how many actual users are taking advantage of this at any one time. In terms of providing service, and understanding the impact of an outage, this is critical to understand. In the mail-order catalog example used earlier, the remote office had insisted that there were only 20 customer service representatives Telneted into the OS/390 system during a given work day. Implementation of a management tool provided visibility to almost double the number of expected sessions due to the addition of finance representatives and non-frontline customer support representatives who were Telneted into the system checking on orders for customers who called in to query on the status. In this case, management became aware of the increased usage of the system from this remote location, and was able to use this to build a case to upgrade several of their servers in response — and enlist the remote site to pay for a portion of the cost! BUILDING THE MODELS It is time to start putting this theory to work to build a baseline understanding of one’s network and its traffic patterns so that one can make adjustments. Just like the air traffic controller, one must always have more than one solution for a particular bandwidth problem or growth requirement. So where does one start? A Simple Baseline Approach Quantify the traffic based on the number of connections and the bytes transferred. Correlate this with bandwidth and IP device utilization. Then determine the activity (load) of each OS/390 application on the system. This assumes an understanding of both port and MVS task access. This information needs to be further delineated by the contribution of each destination, and if possible, down to the user level. Exhibit 46-2 may provide intelligent information that one could use to load-balance the system. Prior to this analysis, a retail food chain believed that the primary access to its systems was to access the MVS-based Web 543

SYSTEM AND NETWORK MANAGEMENT

Exhibit 46-2. Bandwidth utilization.

server it had recently implemented. Current information on specials and marketing programs was available from the intranet, and users had greatly praised being able to access this information in real-time. Because of this, IS had budgeted for two servers to handle all the incoming traffic. But as Exhibit 46-2 shows, Web server access continues to be a small part of the actual activity in this system over a typical week. TN3270 traffic — which is currently being used to access inventory replacement and delivery — is a major driving factor for access to this system. How does one address this? If there is no issue with response time and access (as with this organization), treat this information as a baseline of the system. If response time is being impacted by these real-time queries, one option would be to convert the inventory system to intranet-based access because the two servers were underutilized in this configuration. Another possibility is to move the server to support TN3270 access. Understanding the uses of a system provides the ability to choose from intelligent options such as this. Another example is shown in Exhibit 46-2, where the greatest incoming traffic load can be determined by reviewing bandwidth utilization, shown in number of bytes. Understanding the breakdown of system access and utilization allows network managers to consider a “chargeback” or “charge for access” scheme where remote users jointly fund growth in the organization. 544

Maximizing Mainframe-based WAN Resources CONCLUSION Of course, there are many more issues and metrics in the area of network utilization that can be explored to help one manage a system — from FTP usage to memory utilization on particular routers. As stated earlier, the person responsible for maintenance of the network infrastructure has the responsibility to make sure that technology can adjust to meet the business needs of today’s very competitive market environment. This chapter outlined key policies and metrics one will need to understand in order to be successful at that task. Although the tools one might have available to help will vary in capabilities, a person will be making the choices. Using real-world examples, this chapter has attempted to show that there is often more than one solution to capacity or growth issues. If one has access to the information needed to make intelligent choices, then one will be able to avoid crash landings, and enable end users to quickly and reliably reach their destinations. Notes 1. IDC Computer Networking Architectures: Enterprise TCP/IP Requirements Intensify. 2. IDC Computer Networking Architectures: Intranet Migration Plans. 3. The GartnerGroup Monthly Research Review, April 1998. Web to Host: Lowering the Cost of Terminal Emulation.

545

The Final Word ALTHOUGH THE WEB-TO-HOST MARKET HAS BEEN AROUND SINCE 1996, IT IS STILL IN THE EARLY STAGES OF MARKET EVOLUTION. Many IT organizations have an understandably conservative attitude toward opening up their mission-critical systems to new internal and external users — not to mention the general public at large. This conservatism, combined with the Y2K budgetary and manpower distraction, has resulted in a relatively slow adoption of Web-to-host solutions, even in the face of exponentially increasing competitive and internal pressures for organizations to “dot-com” themselves. This relatively quiet period of market formation has allowed the vendors involved in the market to work many of the kinks out of the products and provide a more complete portfolio of products. Concerns like security and scalability have, to a large degree, been resolved in the current generation of Web-to-host products. IT organizations today have a wealth of stable and proven products from which to choose. There have been a sufficient quantity and diversity of early IT pioneers that have proven the Web-to-host concept and who are already reaping the vast benefits of providing Web-based access to their most critical business systems. University systems, federal and local governments, banks, insurance companies, transport companies, and international conglomerates are all organizations that have benefited from providing browser-based access to legacy systems over the Internet, corporate intranets, or business-to-business extranets. These organizations are slashing costs related to call centers and remote access charges. For-profit organizations are realizing increased revenues, a better bottom line, and increased customer satisfaction as a result of offering their customers a direct and efficient way of doing business. Nonprofit organizations and governmental agencies have discovered that they can vastly streamline and simplify the way they reach their constituents. Now that the dust has settled on Y2K, the Web-to-host products are maturing, and many IT organizations have already “kicked the tires” on one or more Web-to-host approaches, one expects the market to take off. The growth in the market will be led by the replacement of traditional host access solutions (e.g., emulators, displays, gateway, etc.) with Web-to-host solutions. This adoption will be driven by the efficiencies gained by eliminating the desktop and software maintenance issues for host access. And although the installed base of host access is quite large, the potential base of business partners and consumers eclipse the current installed base of 547

WEB-TO-HOST CONNECTIVITY host users. So, the second stage of market growth, in which new users are given access to legacy data, applications, and systems, will be dramatically bigger, faster, and steeper than the replacement market. In a few years’ time, most Internet users will, as a matter of course, interact with decades-old proprietary systems that are running mission-critical, character-based applications. However, these users will not be able to discern that the applications are not running on the most recent Linux server in the enterprise. The appealing user interface and the responsiveness of these aging systems will meet or exceed those of newer systems. And since many legacy systems have superior disaster recovery, fault tolerance, and scalability compared to new Web servers, the user’s experience may actually be enhanced. From a technology standpoint, one expects that there will continue to be natural market segmentation. Thin-client solutions will evolve to support more of the features and functions required by traditional host access users. However, they will maintain an advantage over traditional solutions in that they will provide markedly superior centralized configuration, customization, distribution, metering, and management. Server-centric solutions will be deployed to provide Web access for a new breed of host users that are accessing the host as a part of an overall business-to-business or business-to-consumer set of applications. These server-centric solutions will evolve to provide advanced security, load balancing, fault tolerance, directory integration, and integration with the new generation of objectoriented applications. The purpose of this book was to introduce the reader to the possibilities of Web-enabling legacy host applications and to provide an overview of the relevant technologies associated with Web-to-host solutions. We hope that you have found the selection of articles relevant and useful to answering your questions about Web-to-host, and we welcome your feedback. Please send any comments to us via e-mail to [email protected] or addressed to us through the publisher by mail at:

Auerbach Publications 535 Fifth Ave., Suite 806 New York, NY 10017

Best regards and cheers, Anura Gurugé Lisa M. Lindgren 548

About the Editors Lisa M. Lindgren is an independent consultant, freelance high-tech marketing specialist, and co-editor of Auerbach’s Communications Systems Management handbook and Data Communications Management reference service. She has more than 15 years of experience working for leading enterprise-networking vendors, most recently Cisco Systems. She has an MBA from the University of St. Thomas and a BA from the University of Minnesota in Computer Science. Anura Gurugé is an independent technical consultant who specializes in all aspects of contemporary IBM networking. He has first-hand, in-depth experience in SNA-capable i•nets, SNA/APPN/HPR/AnyNet, Frame Relay, Token-Ring switching, ATM, System Management, and the nascent xDSL technologies. He was actively involved with the Token-Ring switching pioneer Nashoba Networks, which was acquired by Cisco Systems in 1996. Over the last eight years, he has worked closely with most of the leading bridge/router, intelligent hub, FRAD, Token-Ring switching, and gateway vendors, and has designed many of the SNA-related features now found on bridge/routers and gateways. He has also helped large IBM customers to reengineer and totally overhaul their old SNA-only networks. He is the author of Integrating TCP/IP i•nets with IBM Data Centers (1999), Reengineering IBM Networks (1996), the best-selling SNA: Theory and Practice (1984), as well as several other books on SNA, APPN, and SAA. He coedits Auerbach’s Communications Systems Management handbook and Data Communications Management reference service. He has published over 270 articles and is the author of the “Business Communications Review” (BCR) supplements on BCR’s Guide to SNA Internetworking and Beyond SNA Internetworking. He conducts technical and sales training seminars worldwide on a regular basis and has conducted one-day workshops for Networld+InterOp since 1992. In a career spanning 24 years, he has held senior technical and marketing roles at IBM, ITT, Northern Telecom, Wang, and BBN. The editors can be contacted by phone at (603) 293-5855 or by e-mail at [email protected] or [email protected].

549

Index A Academic institutions, 168 Access control, 80, 348 control lists (ACLs), 279 technologies, Web-to-host, 107 Access solutions, Web-to-informationbase, 49–62 knowledge-base development and access using Web, 53–59 ADM medical knowledge base, 56–57 commercial knowledge-base services, 57–59 high-performance knowledge base, 54–55 knowledge base, 53–54 knowledge-base infrastructure, 55–56 University of Indiana knowledge base, 56 meteorological and oceanographic Web-based data access, 50–51 network-centric warfare, 59–61 Web-based metadata access for modeling and simulation, 51–53 DoD’s Modeling and Simulation Resource Repository, 51–53 Navy Modeling and Simulation Catalog, 53 ACLs, see Access control lists Active/active clustering, 445 Active/standby clustering, 444 ActiveX, 105, 387, 394 ADI, see Assured Digital Inc. ADM medical knowledge base, 56 ADO, see Microsoft ActiveX Data Objects Advanced Peer to Peer Networking (APPN), 409, 412 comparison of DLSw and, 416 Implementors Workshop (AIW),409

Agent -based systems, 73, 523 technology, 259 AH, see Authentication Header AIW, see APPN Implementors Workshop American Airlines, 15 American National Standards Institute (ANSI), 172 ANSI, see American National Standards Institute AOS, see Automated Operation and Security Apache, 459, 462 APIs, see Application programming interfaces Applet(s), 95 ActiveX, 387, 394 -based, thin-client emulators, 209 browser-based access using, 393 Java, 18, 105, 394, 452 Application -to-application integration, 171 E-business, 163 E-commerce, 431, 432 failures, 475 legacy, 148, 183, 468 mainframe, 469 programming interfaces (APIs), 180, 277, 380, 528 query engine, 83 services, 23 terminal-oriented, 150 Windows, 134 Application-layer security protocols, for networks, 313–330 ALS 101, 315 interoperability, 316–318 algorithms, 316–317 standard security services, 316 standardized gibberish, 317–318 551

Index layer-by-layer look at security measures, 314–315 monetary transaction security, 326–328 JECF, 328 MPTP, 327–328 OFX, 327 secure payment, 326–327 Secure Electronic Transaction protocol, 318–320 securing electronic messages, 320–323 Privacy Enhanced Mail, 320–321 RIPEM, 321 secure/multipurpose Internet mail extensions, 321–323 Open Pretty Good Privacy, 323 taming HTTP, 323–326 S/HTTP, 324–325 SSL, 325–326 Application servers, 221–230 deployment in enterprise, 227 host integration to, 219 management, 230 overview of application server, 223–226 overview of Web server, 222–223 scalability, load balancing, and fault tolerance, 229 security, 227–229 APPN, see Advanced Peer to Peer Networking ASP, see Microsoft Active Server Page ASR, see Automatic speech recognition Assured Digital Inc. (ADI), 367 Asymmetric key cryptography, 495 Auditing, 349 Authentication, 117 Authentication Header (AH), 366 AutoGUI, 189, 193 Automated Operation and Security (AOS), 368 Automated sentinels, 520 Automated teller machines, 12 Automatic speech recognition (ASR), 64, 75 Automobile dealer-to-manufacturer communications, Web-enabling, 167

B Baan Data Navigator Plus (BDNP), 45 Backbone infrastructure, 415 Backup domain controllers (BDCs), 380 552

Bandwidth utilization, 544 view, 542 Batch message environment, 44 BBN SafeKeyper, 492, 498 BDCs, see Backup domain controllers BDNP, see Baan Data Navigator Plus Best access solution, 390 Beta test, 451 Border node, 414 Broadway, 112 Brochure-ware, 221 Browsing, 513 Business-to-business E-commerce, 1, 429, see also E-commerce, XML-based business-to-business Business-to-business integration, see E-commerce, business-to-business integration using Business databases, enabling consumer access to, 63–78 conversational voice systems, 64–66 database Web publication systems, 66–73 dynamic publication of database information, 69–73 static publication of database information, 69 evaluation and comparison, 75–77 business expense to create, 77 consumer acceptance, 77 potential audience, 75–77 interactive voice response systems, 63–64 Internet agent-based systems, 73–75 recommendations, 78

C CA, see Certificate authority CD-ROMs, 460 Central Processing Unit (CPU), 477 monitor, 506 utilization, 508 CERT, see Computer Emergency Response Team Certificate authority (CA), 300 repository, 304 CF, see Coupling Facility CGI, see Common Gateway Interface Challenge Handshake Authentication Protocol (CHAP), 342

Index CHAP, see Challenge Handshake Authentication Protocol Charge for access scheme, 544 Charleston County Court, 99 Chickering Group, 104 CICS chips, see Complex Instruction Set Computing chips CIM, see Common Information Model; Enterprise data management, with CIM and XML Cipher text, 494 Cisco Custom Queuing, 400 routers, 422 Class-of-Service (COS), 388, 412 Client/server environment, upgrades in, 141 Clustering, 444 active/active, 445 active/standby, 444 concurrent access, 446 COBOL programs, 244 COM, see Microsoft Component Object Model Commercial software business, 197 Common Gateway Interface (CGI), 20, 50, 69, 83, 110 Common Information Model (CIM), 530 Common Object Request Broker Architecture (CORBA), 24, 115, 269 Communication protocols and services, security of, 331–344 Information security manager, 331 Internet protocol, 333–339 file transfer protocol, 337 HTTP, 338–339 Internet protocol v6.0, 335 point-to-point protocol, 338 serial line Internet protocol, 337–338 Telnet, 337 transmission control protocol, 336–337 user datagram protocol, 335–336 protocols, 333 security protocols, 339–343 CHAP, 342–343 L2F, 341–342 L2TP, 342 PAP, 342 PPTP, 341 secure electronic transaction, 340–341 Secure-IP, 342

S-FTP, 340 S-HTTP, 340 SSL, 339–340 services, 343 file transfer, 343 secure shell, 343 Communications transport security, 84 Compaq AltaVista Search Intranet, 127 Complex Instruction Set Computing (CISC) chips, 430 Component architectures, 261 Computer Emergency Response Team (CERT), 345 Concurrent access clustering, 446 Congestion control, 423 Content analyzer software, 453 CORBA, see Common Object Request Broker Architecture; DCOM and CORBA Corporate LAN, 527 Corporate network, one, 409–417 APPN, 412–415 DLSw, 409–412 COS, see Class-of-Service Cost justification, 198–201 case study, 199–201 common misconceptions, 198–199 Coupling Facility (CF), 485 Courier parcel tracking service, 166 CPU, see Central Processing Unit Cross-System Coupling Facility (XCF), 478 Cryptographic hashing, 317 Cryptography, 489 Customer support, 349

D Data displays, 203 encryption standard (DES), 13, 369, 490 entry automated, 205 formats, logical, 204 rules, simplified, 205 input, efficient, 204 legacy, 143 Link Switching (DLSw), 409, 410, 419 validation, 522 Web-to-legacy, 120 Data centers, integration of with intranets, 385–396 553

Index intranet to data center integration technologies, 386–388 too much choice as biggest hurdle, 388–396 bottom line, 396 browser-based access using applets for 3270/5250 emulation, 393–396 browser-based access, via 3270-toHTML conversion, 391–393 Data warehouses, 79–87 architecture, 81–82 implementation, 85–86 extranet, 86 intranet, 85–86 infrastructure, 82–85 application query engine, 83 data warehouse, 84 security, 84–85 Web site, 83 strategy, 80–81 access control and security, 80–81 business relationships, 80 new components, 81 Database(s) access, 85 check pointing, 243 legacy, 174 management systems (DBMSs), 511 problem, 535 status, 507 Database management, Internet and, 511–517 browsing and filtering, 513 data representation, 512 integrity management, 515 interoperability, 515–516 metadata management, 515 query management, 512–513 security management, 514–515 storage management, 514 transaction management, 513–514 DBMSs, see Database management systems DCE, see Distributed Computing Environment DCOM, see Distributed Component Object Model DCOM and CORBA, 269–285 architecture, 276–277 APIs, 277 identity, 277 interfaces, 277 reference counting, 277 554

CORBA defined, 269–273 CORBA architecture, 270–272 history, 270 ORB component and CORBA structure, 272–273 CORBA in real world, 274 DCOM, 274–275 COM architecture, 274–275 DCOM architecture, 275 ease of use, 283 future, 283–284 industry support, 281 interoperability between CORBA and DCOM, 283 language support, 281 maturity, 281–282 performance, 282 platform support, 280–281 programming, 278–279 protocols supported, 283 scalability, 279–280 security, 279 support for World Wide Web, 282 Decision support systems, 129 Defense Modeling and Simulation Office (DMSO), 51 Denial of service, 358 Department of Defense (DoD), 49 DES, see Data encryption standard Deschutes, 439 Desktop maintenance, 142, 144 Management Task Force (DMTF), 441, 529 Digital Signature Standard (DSS), 324 Directory server, 527 Disk space monitor, 506 storage, 484 Distinguished names (DNs), 300 Distributed Component Object Model (DCOM), 269, 274 Distributed Computing Environment (DCE), 256, 283 Distributed database operations, 377 DLSw, see Data Link Switching DMSO, see Defense Modeling and Simulation Office DMTF, see Desktop Management Task Force DNs, see Distinguished names DNS, see Domain Name Server Document Type Definition (DTD), 176 DoD, see Department of Defense

Index Domain Name Server (DNS), 505, 507 DSI, see Dynamic skeleton interface DSLw, choosing between enterprise extender or, 424 DSS, see Digital Signature Standard DTD, see Document Type Definition Dynamic skeleton interface (DSI), 272

E E-business, 163, 165, 224 E-commerce, 13, 45, 165, 313, 465 applications, Internet based, 42 continuum, 174 enabling, 157, 461 initiatives, 169 E-commerce, business-to-business integration using, 41–48 business requirements, 42–43 E-commerce product selection, 44–45 Baan Data Navigator Plus, 45 WebSuite and Gentran server, 44–45 E-commerce solution, 45–46 security, 47–48 technical requirements, 43–44 E-commerce, selecting hardware and operating system software for, 429–534 hardware for E-commerce, 430–434 changing chips, 430–431 mainframes, 431 vendor server products, 431–434 operating system software for Ecommerce, 434–435 Microsoft Windows NT, 434–435 Novell, 435 E-commerce, XML-based business-tobusiness, 171 commerce components, 171 EDI, 172–173 ERP, 173 exposing application services, 179 exposing Web services, 180 integration strategy, 180 interoperability with XML, 175–176 mapping between different DTDs, 178–179 need for business-to-business integration, 174–175 Web, 174 XML, 175

XML-based B2B integration solution, 176–177 XML as RPC message format, 177–178 E-mail, 313 EDI, 36 good natured, 503 secure, 310 E-tailers, 102 ECI, see External Call Interface ECS, see Electronic Commerce services EDI, see Electronic data interchange EDM, see Electronic document management Eicon Aviva Web-to-Host Server, 208 EIS, see Executive information systems EJB, see Enterprise Java Beans Electronic Commerce services (ECS), 310 Electronic commerce services, developing trusted infrastructure for, 299–312 available technologies for electronic commerce, 310–311 secure e-mail, 310–311 secure open EDI, 311 public key certificate infrastructure, 311–312 service attribute authority, 299–309 certificate authority, 300–303 certificate repository, 304 electronic postmark, 304–307 return receipts, 307 storage and retrieval services, 307–309 use of commercial exchange services, 310 Electronic data interchange (EDI), 27 Electronic data interchange, expanding reach of electronic commerce, 27–39 broadening view, 37 components of EDI strategy, 37–38 EDI over Internet, 31 expanding EDI impact, 30–31 FTP-based EDI, 35 growth of EDI, 28 impact of EDI, 28 Internet EDI and electronic commerce strategy, 37 limitations of EDI, 29–30 MIME and E-mail EDI, 36 Web EDI using hub companies servers, 35 Web EDI using Internet value-added service providers, 34 555

Index Web EDI using value-added networks, 33–34 WWW EDI, 31–33 Electronic document management (EDM), 58 Electronic messaging, 320 Electronic postmark, 304 EMP, see Enterprise management platform Employees, high-ranking, 79 Emulation approaches, pros and cons of, 391 Emulators applet-based, thin-client, 209 fat-client, 232 Encapsulating Security Payload (ESP), 366 Encapsulation, 422 Encryption, 365 End nodes (ENs), 413 ENs, see End nodes Enterprise deployment in, 227 -to-enterprise transactions, 397 Java Beans (EJB), 224 legacy systems, 196 management platform (EMP), 539 simplifying of by Web, 532 Resource Planning (ERP), 171, 173 Enterprise data management, with CIM and XML, 527–534 CIM and XML, 530–531 future, 531–532 impact of CIM and XML on DBMS suppliers, 533 putting pieces in place, 529–530 simplification of enterprise management, 532–533 Web emerges as network management panacea, 528–529 Enterprise extender, 419–425 definition, 422–425 choosing between enterprise extender or DLSw, 424–425 efficient message sequencing, 424 larger number of SNA users, 423 no point of failure, 423–424 traffic priority, 424 talking transport, 420–422 connection oriented, 420 encapsulation, 422 link selection, 420 priority queuing, 421 556

reliable transport, 421–422 Enterprise intranet series, 109–118 first-generation Web-to-host product issues, 110 IT manager’s technology perception reality check, 111–112 Java and CORBA/IIOP, 115–116 promise of Web-to-host technology, 111 types of Web-to-host solutions, 112–115 enterprise Web-to-host implementation issues, 113–114 mainframe and midrange Web-tohost and thin client solutions, 112–113 Web-to-host desktop issues, 114–115 Web-to-host benefits, 111 Web-to-host security, 116–117 ERP, see Enterprise Resource Planning Error correction, 205 ESP, see Encapsulating Security Payload Executive information systems (EIS), 23, 128 Extended Recovery Facility (XRF), 484 Extensible Markup Language (XML), 171, 175, 531 External Call Interface (ECI), 243 Extranet, 79, 86, 371, 430

F Failover clustering, 444 Farmers Mutual Protective Association of Texas, 93 Fat-client emulators, 232 Fault tolerance, 237, 375 FC-AL, see Fibre Channel-Arbitrated Loop FedEx, 3, 89, 185, 191 FEP, see Front-end processor Fibre Channel-Arbitrated Loop (FC-AL), 446 File management services, 23 Transfer Protocol (FTP), 35, 52, 337 Final word, 547–548 Firewall management and Internet attacks, 345–360 firewall evaluation criteria, 348–349 firewalls and local security policy, 347–348 firewall techniques, 349–351 application-level gateways, 350–351

Index circuit-level gateways, 351 packet filtering, 349–350 laying groundwork for firewall, 345–347 benefits of having firewall, 346 limitations of firewall, 346–347 developing firewall policy and standards, 351–356 firewall standards, 354–356 legal issues concerning firewalls, 356 policy and standards development process, 352–354 policy structure, 354 reasons for having firewall policy and standards, 351–352 firewall contingency planning, 356–359 firewall outage, 356–357 significant attacks, probes, and vulnerabilities, 357–359 Flat files, 386 Front-end processor (FEP), 540 FTP, see File Transfer Protocol

G Gateway(s) application-level, 350 circuit-level, 351 connection, 112 server, 233 SNA-Web, 389, 395 TCP/IP-to-SNA, 389 General Motors, 89 General Public License (GPL), 457, 458 Generation 5 (G5) notation, 482 GIF, see Graphical Interchange Format G5 notation, see Generation 5 notation Government agencies, publishing public information, 166 GPL, see General Public License Grand Theater, 68 Graphical Interchange Format (GIF), 100 Graphical user interface (GUI), 119, 155, 198, 245 Green-on-black screens, 208, 392 Green screen, 162 emulators, 191, 192 user interface, 186 GUI, see Graphical user interface

H HACL, see Host Access Class Library HAL, see Windows NT Hardware Abstraction Layer Hardware upgrades, 141 Hashing, cryptographic, 317 HCI, see Human-computer interface HDS, see Hitachi Data Systems Hewlett-Packard, 433 High-Level Language Application Program Interface (HLLAPI), 207 High performance routing (HPR), 387, 413, 420 Hitachi Data Systems (HDS), 477 HLLAPI, see High-Level Language Application Program Interface Home banking, 14, 222 Host Access Class Library (HACL), 212, 213 Host integration servers, 231–237 good fit for host integration servers, 236–237 host integration servers, 234–236 mainframes, IBM-styles, 231 thin clients versus server-centric solutions, 232–234 HPR, see High performance routing HTML, see HyperText Markup Language HTML conversion, publishing host data using 3270-to-, 161–169 advantages of, 164–165 application scenarios, 165–169 courier parcel tracking service, 166 government agencies publishing public information, 166–167 online access to student and curriculum information, 168–169 online trust management, 165 Web-based access to host data for mobile sales force, 167–168 Web-enabling automobile dealer-tomanufacturer communications, 167 extending host data, 161–162 flexible to serve many uses and users, 162–163 simple yet powerful architecture, 163–164 HTTP, see HyperText Transfer Protocol HTTPS, see Secure HTTP Hub organizations, 28 Human-computer interface (HCI), 201 557

Index HyperText Markup Language (HTML), 25, 51, 163, 222, 512 output, 122 protocol converters, 147 templates, 215 HyperText Transfer Protocol (HTTP), 25, 222, 253, 338, 462

I IBM, 133, 147 ICF, see Internal Coupling Facility IDC, see International Data Corporation IDE, see Integrated Development Environment IDL, see Interface definition language IETF, see Internet Engineering Task Force IIS, see Microsoft Internet Information Server IMB E-commerce software, 432 Industry models, 267 Information systems (IS), 119, 120, 346 Information systems, Web-to-host connectivity tools in, 119–137 framework for implementation of Web-to-host access tools, 119–120 Web-to-business intelligence systems, 127–132 Web-enabled desktop DSS tools, 128 Web-enabled EIS, 128–129 Web-to-enterprise DSS, 129–132 Web-to-document management and workflow systems, 124–127 Web-based index-search tools, 124 Web-enabled document management and workflow software, 124–127 Web-to-host middleware and RAD development tools, 133–135 Web-to-legacy data, 120–122 Web-to-messaging systems, 123–124 Web to ERP, 133 Information technology (IT), 119, 149, 547 Integrated Development Environment (IDE), 213, 226 Integration server, 177 Integrity management, 515 Intel processors, 437, 439 Interactive voice response (IVR), 63 Interface definition language (IDL), 24, 116, 272, 278 Internal Coupling Facility (ICF), 485 558

International Data Corporation (IDC), 457 Internet Engineering Task Force (IETF), 153, 364, 420, 441 Protocol (IP), 333, 361 security planning, see Security planning, framework for Internet service providers (ISPs), 82, 167, 362 Intranet(s), 86, 371, see also Data centers, integration of with intranets; Enterprise intranet series; Thin-client intranets, evolution to Compaq AltaVista Search, 127 data and, 143 values, 143 Intranets, Web site design and performance for, 449–455 back to basics, 450–451 glitter of Web technology, 455 reasons, 450 remedies, 451–453 site maintenance, 453–454 I/O processors (IOPs), 442 IOPs, see I/O processors IP, see Internet Protocol IP, gracefully transitioning from SNA to, 397–407 bottom line, 407 case against last-minute SNA retrieval, 401 dispelling concerns, 399–400 primary advantages of moving to mainframe IP, 401–404 proven technology to facilitate transition from SNA to IP, 404–406 IS, see Information systems ISG Navigator, 133 ISPs, see Internet service providers IT, see Information technology IVR, see Interactive voice response

J Java applets, 18, 105, 394, 452 benefits of, 254 client object, 258 Commerce Client (JCC), 328 Development Kit (JDK), 257 Electronic Commerce Framework (JECF), 328 implementations, 114 Open Host Interface Objects, 212 Virtual machine (JVM), 25, 111

Index Java, role of in distributed computing, 253–260 agent technology, 259–260 distributed Java applications, 255–259 introspection, 256–257 object serialization, 257 remote method invocation, 255–256 sample RMI transaction, 257–259 Java benefits, 254–255 JavaBeans, component architectures with, 261–268 component architectures, 263–264 industry models, 267–268 JavaBeans, 264–266 events, 266 methods, 265 properties, 264–265 need for components, 262 object-oriented software, 262–263 software containers, 266–267 JCC, see Java Commerce Client JDISS, see Joint Deployable Intelligence Support System JDK, see Java Development Kit JECF, see Java Electronic Commerce Framework Joint Deployable Intelligence Support System (JDISS), 60 JVM, see Java Virtual Machine

K KBML, see Knowledge Base Markup Language KDC, see Kerberos key distribution center Kerberos key distribution center (KDC), 496 Key management, principles and applications of, 489–501 asymmetric key cryptography, 495–496 implementations, 496–500 BNN SafeKeyper, 498–499 Kerberos key distribution center, 496 PGP, 496–497 public key certificates, 499–500 RSA SecurePC, 498 SSL, 500 ViaCrypt PGP, 497–498 key management defined, 491

modern key management, 491–493 principles of key management, 493–495 keys with long life, 494–495 random choosing of key, 493 separate key-encrypting keys, 493–494 recommendations for key management, 500–501 Knowledge base high-performance, 54 infrastructure, 55 Markup Language (KBML), 56 medical, 56 services, commercial, 57 Knowledge management, on Internet, 17–26 administration, 20–22 basic elements of Web/business intelligence solution, 22–23 application services, 23 load balancing services, 23 scheduling, distribution, and notification services, 23 session management services, 23 Web/business intelligence server, 23 challenges of Web, 18–19 enterprise and business intelligence, 18 first principles, 22 scalability, 20 security, 19 supporting technologies, 24–26 CORBA, 24–25 IIOP, 25 Java and XML, 25–26 plumbing, 24

L Lafayette Life Insurance, 90 Language support, 281 Law of diminishing returns, 477 LDAP, see Lightweight Directory Access Protocol Legacy applications, 468 host-based, 134 rejuvenating, 187 Web-enabling, 185 Legacy data, 120 access to, 121 intranets and, 143 Legacy databases, 174 559

Index Legacy platforms, 231 Legacy systems, 107 Legacy traffic, integrating, 383 Lightweight Directory Access Protocol (LDAP), 229, 440 Linux Software Map (LSM), 461 Linux, Web and, 457–463 Apache Web server, 462–463 applications, 460–461 enabling E-commerce, 461 operating system, 457–460 features of Linux, 459–460 hardware requirements, 458 installing Linux, 459 obtaining Linux, 458 PHP, 461–462 Load balancing services, 23 Local storage, 17 Logical Partitioning (LPAR), 481 Lotus Notes, 493 LPAR, see Logical Partitioning LSM, see Linux Software Map

M Macs, 164 Mainframe(s), see also WAN resources, maximizing mainframe-based applications, 469 -based approach to Web, 470 configuration, humongous, 481 IBM, 133 reappearance of, 431 Market segmentation, 548 MDACs, see Microsoft Data Access Components Memory utilization, 545 Message environment, batch, 44 queue, 46 sequencing, efficient, 424 Metadata management, 515 Microcomputer age, dawn of, 443 Micro Payment Transfer Protocol (MPTP), 327 Microsoft, see also Windows 2000, interoperability for enterprise Active Directory, 376, 379 Active Server Page (ASP), 100, 223 ActiveX Data Objects (ADO), 248 Component Object Model (COM), 216, 240, 263 Data Access Components (MDACs), 239 560

Internet Information Server (IIS), 124 Message Queue Server (MSMQ), 246 NT, competition of with NetWare and UNIX, 434 Pocket Internet Explorer, 168 Transaction Server (MTS), 241 Windows NT Enterprise Edition, 438 Hardware Abstraction Layer (HAL), 438 server, 144, 431 support for, 379 Middleware, 81, 406 evaluating object, see DCOM and CORBA proprietary, 112 MIMEs, see Multipurpose Internet Mail Extensions MNPS, see Multinode persistent sessions Modeling and Simulation Resource Repository (MSRR), 51 Monetary transaction security, 326 Monitoring strategy, 505 systems, 504 MPTP, see Micro Payment Transfer Protocol MSMQ, see Microsoft Message Queue Server MSRR, see Modeling and Simulation Resource Repository MTS, see Microsoft Transaction Server Multinode persistent sessions (MNPS), 414, 482 Multipurpose Internet Mail Extensions (MIMEs), 36

N Navarre Corporation, 100 NDAP, see Novell Directory Access Protocol NDS, see Novell Directory Service Netscape Directory Server, 370 Navigator, 493 NetWare, 234 competition of Microsoft Windows NT with, 434 support of TCP/IP by, 440 Network audit capability, 346 -centric warfare, 59 nodes (NNs), 413

Index Operating Center (NOC), 371 OSs (NOSs), 443 Network directory services, evolving world of, 373–381 active directory, 379–381 directory service overview, 374 features, 374–376 customization capability, 375–376 enhanced security, 376 fault tolerant operations, 375 single log-on, 375 single point of administration, 375 Novell’s NDS, 376–379 distributed database operations, 377 Novell directory access protocol, 378 objects and object management, 377 schema, 378 supporting services, 378–379 support for Windows NT, 379 product comparison, 381 New On Line Administration System (NOLAS), 91, 470 NNs, see Network nodes NOC, see Network Operating Center NOLAS, see New On Line Administration System Nonrepudiation, 299, 316 NOSs, see Network OSs Notifications, 267, 522 Novell, 435 Directory Access Protocol (NDAP), 378 Service (NDS), 372, 373, 376 HostPublisher, 161, 208

O Object Linking and Embedding Database (OLE DB), 247 Management Group (OMG), 24, 269 Request Broker (ORB), 24, 225 Transaction Services (OTS), 280 Object-oriented languages, 263 software, 262 OCXs, see OLE controls ODA, see Office document architecture ODBC, see Open Database Connectivity Office document architecture (ODA), 512 OFX, see Open financial exchange

OHIO, see Open Host Interface Objects OIA, see Operator Information Area OLAP, see Online analytical processing OLAP agents, 519–525 agent-based systems, 523–525 agent engine, 523 multiple distribution mechanisms, 524 open systems, 524–525 personalized rules and results, 523 rules of rule building, 523–524 viewing results in context, 524 delegation, 519–521 OLAP agents, 521–523 software agents defined, 521 OLE controls (OCXs), 275 OLE DB, see Object Linking and Embedding Database OMG, see Object Management Group Online analytical processing (OLAP), 520 Online investing, 14 Open Database Connectivity (ODBC), 240 Open financial exchange (OFX), 327 Open Host Interface Objects (OHIO), 159 OpenPGP, see Open Pretty Good Privacy Open Pretty Good Privacy (OpenPGP), 323 Open systems, 524 Operating system software, see E-commerce, selecting hardware and operating system software for Operator Information Area (OIA), 214 ORB, see Object Request Broker Order-entry system, 467 Organizational unit (OU), 377 Organizations, dot-com, 547 OS trends and updates, 440 OTS, see Object Transaction Services OU, see Organizational unit

P Package tracking, 222 Packet filtering, 349 PAP, see Password authentication protocol Paralegals, 99 Parallel Sysplex, 475–486 bottom line, 486 coupling, 485–486 divide and conquer, 481–482 going beyond loosely coupled, 477–481 multiprocessor systems, 476–477 nonstop working, 482–485 561

Index Password authentication protocol (PAP), 342 Payload corruption, 315 Payment information (PI), 319 PCs, 164, 405 PDC, see Primary domain controller Peer Web Services (PWS), 124 PEM, see Privacy Enhanced Mail Pentium -based chips, 430 II processors, 439 Persoft, 147 PGP, see Pretty Good Privacy Physical units (PUs), 411 PI, see Payment information Ping monitor, 506 PKI, see Public Key Infrastructure Platform support, 280 Plug-ins, installing, 21 Point-and-click interface, 99, 123 Point-to-point protocol (PPP), 338, 364 Point-to-point tunneling protocol (PPTP), 341 PPP, see Point-to-point protocol PPTP, see Point-to-point tunneling protocol Pretty Good Privacy (PGP), 496 Primary domain controller (PDC), 380 Priority queuing, 421 Privacy Enhanced Mail (PEM), 311, 320 Processing speeds, 449 Process monitor, 506 Programming technologies, architectures and, 251 Proprietary application server, 113 Proprietary middleware, 112 Protocol(s), 333 translation, 423 violations, 537 Prototypes, 199, 202 Public information, government agencies publishing, 166 Public key certificates, 499 cryptography, 317 Infrastructure (PKI), 312 Purchase order template, 32 PUs, see Physical units PWS, see Peer Web Services

Q Query management, 512 processing, 513 562

R RAS, see Remote access server RealAudio, 348 Reduced Instruction Set Computing (RISC) chips, 430 Relational OLAP, 521 Remote access server (RAS), 361 Remote Method Invocation (RMI), 225, 255 Remote Procedure Call (RPC), 177 Reservation Protocol (RSVP), 400 Return on investment (ROI), 14, 89, 538 Return receipts, 307 Riordan’s Internet Privacy Enhanced Mail (RIPEM), 321 RIPEM, see Riordan’s Internet Privacy Enhanced Mail RISC chips, see Reduced Instruction Set Computing Risk analysis, 352 RMI, see Remote Method Invocation ROI, see Return on investment ROLAP, see Relational OLAP Router status, 507 RPC, see Remote Procedure Call RSA SecurePC, 498 RSVP, see Reservation Protocol

S Sabre, Inc., 97 Secure Electronic Transaction (SET), 318, 340–341 Secure file transfer protocol (S-FTP), 340 Secure HTTP (HTTPS), 229 Secure HyperText Transfer Protocol (S/HTTP), 324, 340 Secure payment (S/PAY), 326 Secure Sockets Layer (SSL), 5, 80, 156, 279, 325 Secure virtual networks (SVNs), 335 Security, 287 management, 514 protocols, 339, see also Application-layer security protocols, for networks Security planning, framework for Internet, 289–298 connecting to World Wide Web, 289–291 full buffered connection, 290 full direct connection, 290 standalone connections, 290–291

Index encryption software and authentication, 293–294 authentication, 294 encryption, 293–294 firewalls, 294–296 host-based application-level firewalls, 295–296 router-based IP-level firewalls, 295 legal issues, 297–298 patching and preventing security holes, 291–293 identifying security holes, 292 monitoring hacker activity, 292–293 secure interfaces, 296–297 S-HTTP, 296–297 SSL, 296 securing network environment, 291 Self Timed Interconnect (STI), 486 Serial line Internet protocol (SLIP), 337 Server(s) application, host integration to, 219 Domain Name, 505 gateway, 233 host integration, see Host integration servers infrastructure, 427 integration, 177 Microsoft Internet Information, 124 NT, 93 proprietary application, 113 remote access, 361 UNIX, 4, 93, 431, 466 Web/business intelligence, 23 Windows NT, 144, 431 Server issues and trends, 2000, 437–447 32-bit Intel processors including Deschutes, 439 64-bit processors, 439–440 clustering, 444–446 active/active clustering, 445 active/standby clustering, 444–445 concurrent access clustering, 446 FC-AL, 446–447 hot pluggable PCI, 443–444 I2O, 442–443 OS trends and updates, 440–441 thin client support, 446 8-way Intel multiprocessor systems, 438–439 Web management, 441 Service attribute authority, 299 Location Protocol (SLP), 156

Session hijacking, 357 management services, 23 SET, see Secure Electronic Transaction S-FTP, see Secure file transfer protocol SGML, see Standard generalized markup language Shipping industry, 185 S/HTTP, see Secure HyperText Transfer Protocol SiteScop/SiteSeer, 509 SLIP, see Serial line Internet protocol SLP, see Service Location Protocol SMP, see Symmetric Multiprocessor SNA, see System Network Architecture SNI, see SNA Network Interconnection SOCKS, 366 Software agent defined, 521 AutoGUI, 193 business, commercial, 197 community, needs of, 147 containers, 266 content analyzer, 453 distributor of consumer, 101 encoding, 489 filtering agents, 522 object-oriented, 262 Web server, 459 S/PAY, see Secure payment Split-stack operation, 7 Spoofing, IP source address, 357 SSL, see Secure Socket Layer Standard generalized markup language (SGML), 512 Standardization, 153 Static information, publication of, 145 STI, see Self Timed Interconnect Stock trading, 222 Storage management, 514 and retrieval services, 307 Strong authentication, 342 Sun Microsystems, 147, 432, 433 SVNs, see Secure virtual networks Symmetric cryptography, 317 Symmetric Multiprocessor (SMP), 476 SYN Flooding, 359 System Network Architecture (SNA), 149, 419 Network Interconnection (SNI), 404 revival, last-minute, 401 System and network management, 487 563

Index

T TCO, see Total cost of ownership TCP, see Transmission control protocol TCP/IP, see Transmission Control Protocol/Internet Protocol Technology perception reality check (TPRC), 111 Telnet, 248 Terminal-oriented applications, 150 Text-to-speech (TTS), 64, 75 Thin-client intranets, evolution to, 139–148 future of intranets, 145–148 new browser/Web applications, 146 people challenges, 147 publication of static information, 145 technology challenges, 147–148 Web access to legacy hosts, 146 what to keep eye on, 146 Internet-intranet connection, 139–143 changing corporate environment, 140–142 intranets and distributed computing, 142 intranets and legacy data, 143 intranets and Web browsers, 142–143 intranets and Web servers, 143 intranet trends, 142 intranet values and concerns, 143–145 top three concerns, 145 top three values, 144 TIC, see Token Ring interface coupler TLS, see Transport Layer Security TN3270 and TN5250 Internet standards, 149–159 enterprise data and logic, 149 Internet integration, 157–159 interoperability, 155–156 enhancements, 156 programming, 156 looking forward, 159 newer platforms and devices, 150–152 protocols, 153–155 clients, 155 servers, 153–155 standardization, 153 user productivity and confidence, 149 Token Ring interface coupler (TIC), 411 Toolkit approach, 188 564

TOS, see Type of Service Total cost of ownership (TCO), 466, 541 TPRC, see Technology perception reality check Traffic priority, 424 Transaction management, 513 processing (TP), 279 Transmission control protocol (TCP), 336 Transmission Control Protocol/Internet Protocol (TCP/IP), 151, 253 -centric environment, 399 networks, SNA vs., 536 Transport Layer Security (TLS), 156 Trans World Airlines, 15, 89 Travel booking, 222 reservation systems, 97 TTS, see Text-to-speech Type of Service (TOS), 421

U UDP, see User Datagram Protocol Uniform resource locator (URL), 33, 66 Universal identifier (UUID), 278 UNIX, 3, 234 alternative servers, 466 competition of Microsoft Windows NT with, 434 platforms, 228 servers, 4, 93, 431 workstations, 164, 405 UPS, 185 URL address, of business, 66 Usability design, for Web-based applications, 197–206 attaining usable Web-based application interfaces, 202–206 automated data entry, 205 concise instruction levels, 203 confirmation of destructive actions, 204 consistent use of color, 203 direct usability of information, 202–203 distinct naming, 203 ease of navigation through data displays, 203 efficient data input, 204 error correction, 205–206 feedback on data input, 205 indication of function actuation, 204

Index logical data entry formats, 204 required and optional field differentiation, 205 simplified data entry rules, 205 cost justification, 198–201 case study, 199–201 common misconceptions, 198–199 recommended course of action, 206 usability basics, 198 Web design challenge, 201–202 User Datagram Protocol (UDP), 335, 364 groups, 19 profile, 114 User interface rejuvenation, Web-based technologies for, 185–196 meaning of rejuvenating legacy applications, 186–187 obstacles in Web-enabling legacy applications, 186 options for rejuvenating legacy applications, 187–196 customizable AutoGUI approach, 189–196 knowledge-based approach, 188–189 noncustomizable AutoGUI approach, 189 toolkit approach, 187–188 reason for Web-enable legacy applications, 185 User interface rejuvenation methodologies, available with Webto-host integration solutions, 207–217 bottom line, 217 rejuvenation options with appletbased, thin-client emulators, 209–215 rejuvenation options with 3270/5270-to-HTML conversion, 215–217 UUID, see Universal identifier

V Value-added networks (VANs), 29, 33, 41, 310 Value-added service provider (VASP), 34 VANs, see Value-added networks VASP, see Value-added service provider Vendor server products, 431 ViaCrypt PGP, 497 Virtual private networks (VPNs), 335, 402

Virtual private networks, Internetbased, 361–372 advantages, 362–363 applications, 361–362 carrier services, 370–372 implementation, 363–367 IPsec, 365–366 L2F, 364–365 L2TP, 365 PPTP, 364 SOCKS, 366–367 vendor offerings, 367–370 Assured Digital, 367–368 Bay Networks, 369–370 VPNet Technologies, 368–369 Visual Basic, 282 VM/ESA, Web-to-host with, 465–473 good news/bad news, 468–469 mainframe-based approach to Web, 470–472 benefits, 471–472 challenges, 470 solution, 471 platform for Internet, 467–468 unlock power of mainframe applications, 469–470 VPNs, see Virtual private networks

W WAN link, 527 WAN resources, maximizing mainframebased, 535–548 building models, 543–544 meaning of performance, 539–543 SNA vs. TCP/IP networks, 536–539 different camps, 538 making purchasing decisions, 538–539 technology decisions, 537–538 Warning banner, sample, 356 Watcher agents, 522 Web, see also World Wide Web application security, 323 -based systems, scalability of, 19 browser, 109, 162 /business intelligence server, 23 design challenge, 201 master, 82 -to-messaging systems, 123 monitoring strategy, 509 server access, 84 software, 459 565

Index site design, see Intranets, Web site design and performance for technology, glitter of, 450, 455 usage policy, 452 Web-to-host integration, 3–15 applications for, 1 bottom line, 14 immediate uses for, 14–15 key advantages, 13–14 major techniques for, 5–12 3270/5250-to-HTML conversion, 8–11 end-to-end SNA transport mechanisms, 11–12 full-function 3270/5250 emulators, 5–7 programmatic approaches, 11 thin-client 3270/5250 emulators, 7–8 real-life case studies of, 89–106 bottom line, 105 Charleston County Court, 99–100 Chickering Group, 104–105 Farmers Mutual Protective Association of Texas, 93–97 Lafayette Life Insurance, 90–93 Navarre Corporation, 100–103 Sabre, Inc., 97–99 security concerns as excuse, 12–13 similarity of hosts, 4–5 Web server monitoring, 503–510 collecting and using historical data, 508–509 identifying critical Web server components, 504–505 implementing Web monitoring strategy, 509 importance of monitoring, 503 internal versus remote monitoring, 507–508 managing problems, 508 monitoring strategy, 505–507 SiteScope/SiteSeer, 509–510 whoami, 459 Wide area network (WAN), 361, 527 Windows 2000, 239–250 bottom line, 250

566

COM-oriented interoperability, 240–241 COMTI, 244–245 conspicuous omissions, 249 data interoperability with IBM systems, 247–248 integrating IBM CICS, IMS, and DB2 transactions, 241–243 interoperability for enterprise, 239–250 MQSeries-to-MSMQ bridge, 245–247 summary of interoperability functions, 249–250 application interoperability, 249 data interoperability, 249 UNIX interoperability, 250 Novell interoperability, 250 2-phase commit and COMTI, 243–244 UNIX and NetWare interoperability, 248–249 Winsurf Mainframe Access (WMA), 7, 102, 103 WMA, see Winsurf Mainframe Access Workflow Status Reports, 127 Workstation users, 3 World Wide Web (WWW), 31, 536, see also Web beginning of, 140 transactions, 313 WWW, see World Wide Web

X XCF, see Cross-System Coupling Facility XML, see Extensible Markup Language XRF, see Extended Recovery Facility

Y Y2K challenge, 385 concerns, 397 dust settled on, 547 travails, 89

Z Zero-footprint clients, 234