Web to Host: A Plethora of ClearPath Choices

Unisys takes an "if you need something, we will have it for you" approach in providing tools to Web-enable applications that execute on the ClearPath HMP servers and its older 2200 and A Series systems.

• 11/01/1999

A packrat. That is one way to look at the crammed corner hardware store that hangs out its sign saying, "If we ain’t got it, forget it!" (This same saying could be applied to many of our desks!) A more positive way of looking at the saying is, "If you need something, we will have it for you." And this is the way Unisys approached providing tools to Web-enable applications that execute on the ClearPath HMP (Heterogeneous Multiprocessing) servers and older 2200 and A Series systems.

Electronic business has been around for a long time in the form of, for example, electronic data interchange (EDI). With the advent of the Internet, new business models have evolved.

When the Web first came on the scene, there was a sudden rush to publish a promotional Web page. This progressed to using Internet technology inside the organization (intranets) for communications, such as human resources and news. Internal use grew to include other intra-business applications, such as call center automation and direct order entry.

The next Web expansion, conducting business-to-business electronic commerce (i.e., extranets), continues to grow. Collectively, major corporations conduct billions of dollars of business over the Web. Usually, this involves an organization’s business partners, including customers, dealers, suppliers and vendors. Supply-chain management is key here.

Worldwide Internet commerce revenue in 1998 was $47 billion. This is expected to grow to an astounding $1,264 billion in 2003 – yes, you read it correctly – to well over a trillion dollars. The United States alone represents 56 percent of that total, and Western Europe is 34 percent.

All of the information in this article is equally applicable to the Internet, to an intranet, and to an extranet. Before we describe alternatives, you should first examine your forest of applications, databases and workflows, and decide which applications you want to keep and which ones can or should be completely rebuilt. There is an old application-development adage that says that if you have to change 25 percent of an application, you are better off completely redesigning and rewriting it from scratch. On the other hand, as labor costs skyrocket, keeping them seems more and more attractive. Regardless of the decision, base it on your evolving business rules and logic, and where you want to be in one, three and five years.

Web-enabling applications is the perfect opportunity to perform this self-diagnosis. Other reasons to rewrite include performance and scaling improvements, Year 2000 considerations, ease of adding future upgrades, platform changes, migration from a database-centric (e.g., SQL – structured query language) to transaction-centric (e.g., Open/OLTP – online transaction processing) model, and so on.

For purposes of this article, we assume a desire to keep existing applications and databases and a wish to provide them with Web front ends. Implicit in this decision is the choice to use the ubiquitous Web browser as the application front end. This usually forces a choice between Netscape Navigator and Microsoft Internet Explorer (IE) to be made as the primary browser of choice. IE and Navigator have been certified by Unisys to work with the Web-enablement tools described in this article, and many other browsers are compatible and will also work.

Selection of a Web browser as the primary interface presents several advantages aside from a merely modernistic look-and-feel. It can somewhat reduce training costs since only an intuitive Web browser interface is required; however, the business processes displayed inside the browser must still be learned and understood. As a reminder, when an application is being rolled out to the general public across the Internet, the only training they will receive is, sort of, on-the-job training, by using the application directly.

Choosing browser interfaces for applications can eliminate "fat-client" application roll-outs, with the benefits of reducing deployment costs and shortening application roll-out timeframes; reducing client system hardware and software upgrade requirements; and eliminating requirements for terminal emulators. It can increase end user satisfaction by actually hiding the type of system to which the user is connected. It can also disguise or eliminate the need for the sometimes-peculiar system and keyboard mappings.

Another factor to consider is how "static" the Web pages need to be. This influences the model chosen, including whether to pick a more traditional enablement model versus, a Java-based implementation.

As part of the implementation, you will need to decide where the Web pages will be served from, either the Intel node or the OS2200 or MCP (A Series Master Control Program) node. This article covers the non-Intel node in detail. For the Intel side, Netscape Web servers and the Microsoft Internet Information Server (IIS) have been verified with Unisys Web-related products. Netscape Enterprise Server is available from Netscape, and Netscape FastTrack is actually bundled with the SCO (Santa Cruz Operation) UnixWare version of ClearPath HMP.

Another decision is how database access is to be provided, directly, through database queries via SQL, ODBC (open database connectivity), and JDBC (Java database connectivity), or through applications and transactions acting as front ends to the database.

The extent to which an application can be Web-enabled varies, usually depending on the situation. Thus, categorizations, based on the extent of Web enabling and the corresponding value-added capabilities, are used. It is based on the Web client/server model, using commercial off-the-shelf software such as browsers, custom client-side ActiveX Controls and Netscape plug-ins, and Unisys agents, application servers, information engines, Web gateway software and value-add Open/OLTP components. The methodology is consistent for both ClearPath HMP IX and NX platforms, including both NT and UnixWare variants.

Simple Web modernization includes terminal emulation and face lifting. Terminal emulation involves the creation of Web-enabling applets or Controls. This emulates the 2200 or A Series "green screen" terminal environment and protocol, and then displays those screens unmodified within the Web browsers.

Face lifting takes this one step further. It automatically transforms the green-screen appearance and data into HTML through scripting and a form-based layout, which is then displayed within the browser.

Another approach integrates a Web application-server paradigm with the existing application. Here, the application is integrated with Web application servers that incorporate business rules and logic, provide information processing and graphic engines, integrate external applications, and provide application management and security.

At the top of the Web-enablement pyramid are Web transactions. These provide across the Internet the ACID transactional middleware properties of atomicity, consistency, isolation and durability that we have grown to know and love about Unisys mainframe-class servers. These properties represent management and recovery for a Web enterprise-application environment, including maintaining the ACID properties across multiple applications, data sources and even systems.

A Web server is required to serve up all forms of these Web pages. When a browser requests a page, the Web server software accesses the existing application via modernizing-agent components, application servers, or OLTP transactional gateways. The Web server can be an NT-based Web server, or it can reside on the OS2200 or MCP node. On the HMP IX Web server, the WebTS product, described later, is used, and, similarly, the Atlas Web Server, also described later, is used on the HMP NX. On the NT side, Microsoft Internet Information Server, Netscape Enterprise Server or FastTrack, or other popular Web server could be used.

The interfaces to these existing applications vary depending on the type of target application. The Web server and HTML interfaces can also take several forms. These include APIs (application programming interfaces), scripts, and applets, including such popular interfacing techniques as Microsoft OLE (object linking and embedding), Java applets, CGI (common gateway interface) and Perl scripts, and ActiveX Controls, JavaBeans, and Netscape plug-ins.

ActiveLINC allows Web developers to create Java applets to front-end all or part of a LINC system using automatically generated Java classes by providing Component client-side interfaces to the existing LINC applications.

There are many ways to enable Web access, as simple as running the generated sample interface applications as applets from the browser. More interesting Web pages, though, can be built using scripting languages and the ActiveLINC Component interfaces to remotely access the LINC applications.

Some Web servers, such as Microsoft IIS, support what is called "server-side scripting" to create active server pages (ASPs). This allows Web pages to be constructed on-the-fly using a server-side scripting language, such as VBScript (Microsoft Visual Basic Scripting Edition).

When scripting is not used, a Web server retrieves a requested Web page (from LINC, in this case) and sends it along to the Web browser. With server-side scripting, the Web server first inspects the page’s contents for any embedded scripts. This allows the Web server to retrieve data from the LINC application in real-time and build the HTML page dynamically, which is then sent to the client system.

Using the ActiveLINC Generator, which is part of the ActiveLINC SDK (software developers’ kit), Java classes and ActiveX Components can be built from LINC Ispec definitions (i.e., from LINC transactions). It also allows optional Java applets for GUI (graphical user interface) forms to be generated. ActiveLINC generates a set of ActiveX or JavaBeans interfaces to the selected Ispecs. These JavaBeans provide the COM and DCOM interface to standalone workstation client applications written in, for example, C++, Visual Basic, or Java. They also provide the interface to scripted Web pages and to commercial-off-the-shelf products like Microsoft Word and Excel. To test and debug the generated interface, the ActiveLINC Viewer is used.

In an operational situation, a direct TCP/IP connection is provided via RATL (remote access to LINC), which is the same interface used by PowerClient and PowerClient Web Agent. RATL allows applications developed using varied development tools to access LINC applications, including Visual Basic, Java applets, and HTML-scripted Web pages, using ActiveX and/or JavaBeans to communicate.

ActiveLINC user interface programs and Components are standard Java classes, loaded by the browser, as required, by Java and Web technology.

PowerClient Web Agent is a middleware component that runs on a Microsoft Windows NT Server and allows LINC applications from OS2200 or MCP to be displayed without modification across the Web using a PowerClient graphical form.

LINC produces graphical forms for Windows in a format called screen control language (SCL). PowerClient converts the SCL screens into HTML, providing the communications between the Web server and an existing unchanged application. The same user interface that is seen by an internal LAN-based user is available to remote users via a browser.

To create the graphical versions of the screens, PowerClient Web Agent Site Builder or LINC Development Assistant III (LDA III), which also runs on NT, is used. Once built, this generated standard HTML can be edited by any HTML editor for modification or enhancement. GUI characteristics such as fonts, colors, buttons, and both static and dynamic lists and images are supported by PowerClient Web Agent.

These graphical screens can be used as pure desktop thin-client screens for data entry purposes only. Conversely, the Web page can contain links to the actual LINC application.

When the user visits a thus-modernized Web page, the Web server receiving the HTTP request passes the request to Web Agent. Web Agent establishes a session with the appropriate LINC application. Web Agent retrieves the requested Web page from an underlying repository of modernized screens that it maintains. The repository is populated by exporting the screens once their development is completed.

Web Agent uses ActiveX Controls to display the form in the proper format for the browser. It operates with Microsoft IIS and Netscape Web servers, usually running on the same system as the Web server.

PowerClient Web Agent supports SSL (secure sockets layer) for secure communications; see the Security section for more details on SSL.

NX/WebStation for Java quickly Internet-enables most MCP server-based COMS (Communications Management System) applications for access by a Java-capable browser, such as Microsoft Internet Explorer and Netscape Navigator.

NX/WebStation for Java is a Java applet, making it a cross-platform client/server application with execution taking place on the client system. Until downloaded by the client system, it resides in the MCP environment. However, no part of NX/WebStation for Java runs in the MCP environment.

NX/WebStation for Java operates by mapping standard T27-terminal data streams of COMS applications to HTML GUI components; the old-style "green-screen" forms are converted to GUI interface elements. Once mapped, the resulting form can be presented within any HTML page.

The existing MCP applications require no modifications to use NX/WebStation for Java, and its use requires no intermediate gateways. Additionally, no manual conversion of terminal-based forms or screens is required.

NX/WebStation for Java sustains a transaction performance and scalability similar to that of an existing terminal network.

To operate, NX/WebStation for Java requires a Java-capable browser, the ClearPath NX/Atlas Web Server, the COMS Connect Facility (CCF), and a COMS third-generation language (3GL) or LINC application.

Open/OLTP supports industry-standard online transaction processing via X/Open DTP (distributed transaction processing) interfaces, allowing calls and responses within or outside of a global distributed transaction. One of its defining characteristics is that it supports two-phase commit database protocols, which allow records in multiple databases, potentially distributed across multiple heterogeneous platforms, to be updated in unison as if they were controlled by a single database.

Open/OLTP Pathway provides access to OS2200 Open/OLTP applications from clients resident on UnixWare platforms. It is a Unisys version of BEA System’s Tuxedo Workstation (/WS), more tightly integrated into the ClearPath HMP IX system. /WS provides a remote OLTP client capability originally designed to run on a user’s workstation. Early releases of ClearPath HMP servers used /WS in the NT environment to support transaction processing from the NT environment to the MCP environment.

Open/OLTP Pathway software contains the programming libraries and documentation for developing and executing Open/OLTP client applications. OS2200 services can be called from the Intel-based environment. Pathway can also used as a terminal concentrator for dumb terminals.

WebTx is the most complicated product to describe because its coverage is so broad. It is middleware for the ClearPath IX and NX servers that runs on the Intel node under Microsoft Windows NT Server or SCO UnixWare. It connects the browser to transactions that execute on the OS2200 and MCP side.

WebTx provides access to the applications of the various transaction processing systems, including Open/OLTP (on MCP and OS2200, as well as BEA’s Tuxedo), OS2200 TIP (transaction processing) and HVTIP (high-volume transaction processing), and MCP COMS direct windows.

It provides access to applications written in MAPPER, LINC, and many third-generation languages. It also provides access to maturing technologies, such as Microsoft’s Windows NT Server COM (component object module), DCOM (distributed COM), and MTS (Microsoft Transaction Server).

On the flip side, WebTx provides access from HTML pages, Java and JavaBeans applets, NT DCOM applications, and ActiveX as well as CORBA (common object request broker architecture) clients.

Here is how it works. On input from a browser, WebTx maps the HTML forms to Open/OLTP service calls on ClearPath HMP IX and NX systems. It operates with Microsoft and Netscape Web servers in either an NT or UnixWare environment. Through this means, contemporary NT technologies can be used on the Web side, while retaining use of the industrial-strength nature of the enterprise-class transaction processing infrastructure. Likewise, on output, Open/OLTP passes the output information to WebTx, which then converts it to HTML.

Technically speaking, WebTx interfaces to Pathway or HTP/ic, thereby providing access to the Open/OLTP transaction processing system.

WebTx has a gateway to MAPPER, LINC, and Tuxedo applications.

WebTx on both the HMP IX and NX also supports access to transactions modified to use COMAPI (Communications API), a sockets-like interface available in HMP 4.0 and later releases.

Because WebTx runs on the Intel node and Open/OLTP runs on the OS2200 and MCP side, this separation provides a natural and added layer of security, keeping the enterprise data and server isolated from the Internet. WebTx can also be incorporated with Cool ICE to simplify administration of the HTML pages and to add a security layer for the application.

Commencing in HMP 4.0, the High-performance Transaction Processing Interconnect, which is a transport mechanism for Windows NT, gives WebTx access to Open/OLTP services. HTP/ic provides an environment that allows WebTx gateway applications on a Microsoft Windows NT node to interconnect programmatically with applications on an OS2200 or MCP node. It is based on XATMI (X/Open application transaction management interface) and OSI TP (open system interconnection transaction processing) standards.

HTP/ic replaces Pathway only for the Windows NT node; UnixWare nodes continue to use Pathway. Among other features, it provides a performance improvement for WebTx operations.

An application developer uses a WebTx gateway to assist in creating an application program that uses HTP/ic calls to access the remote services.

Cool ICE (Internet commerce enabler) is an enterprise-grade Web application server and development tool for creating Web applications that runs on an Microsoft Windows NT server or UnixWare platform. It also allows for dynamically creating HTML Web pages that include data from existing databases. Although its primary mission is to leverage and integrate potentially disparate existing databases, data warehouses, and application reports, it also provides the ability to create, organize and manage new Web applications via a single integrated product approach.

Cool ICE integrates multiple databases from one or more suppliers in a single environment. For example, it can combine data from Oracle Financials, PeopleSoft HR running under Sybase, and an in-house application developed in Progress. In short, it can integrate with any database through ODBC. It of course integrates ClearPath HMP databases, including Oracle, Sybase, Informix, DB2, RDMS 2200, LINC, DMSII, and MAPPER databases. In addition to ODBC, it provides interfaces for SQL and OLTP data and application access. It supports industry-standard languages, such as JavaScript and VBScript.

Cool ICE can organize and manage resources other than those it develops. Typical Cool ICE administrative functions include adding and deleting services, functional groupings, and utilization statistics. Through this means, the Cool ICE security can prevent access by unauthorized users to those resources. For example, it can be used to control access to ClearPath HMP applications that have been Web-enabled using NX/WebStation for Java, PowerClient Web Agent, WebTS, and JavaClient for DPS.

Cool ICE provides application-level security based on security profiles. Security profiles can give individualized access to groups of users with common interests, such as applications, functions, objects, documents and services.

Cool ICE is a powerful tool to Web-enable MAPPER applications. With Cool ICE, MAPPER applications can have embedded HTML, JavaScript, and graphic images. Yet, the access to the MAPPER applications can still be controlled by MAPPER security.

Because the Web does not save state between browser requests, there is no continuous connection between the client system and the MAPPER host. Thus, the application cannot maintain its state in the usual way, saving results from one screen to the next. Instead, something called server-side variables are utilized. There are several types, including ones to share information across all services in a session, to share information across all services in an application in a session, and to share information within a single service in a session.

Using Cool ICE with MAPPER implies that the historic role MAPPER has always played – data storage, business logic, screen logic, screen display, and input validation – changes. Business logic remains with and is managed on the MAPPER system, with MAPPER security still available. However, much of the workload is taken on by Cool ICE, building and displaying the screens. And with JavaScript routines to validate user input on the client system, that too is offloaded. Thus, the role of MAPPER becomes one of a repository for executable business logic serving up data.

When using Cool ICE, a Web server is still required, as are a firewall, a Web design and authoring tool (such as Front Page), and a point-and-click application builder to support scripting.

WebTS, the Web transaction server, is a high-volume Web server that runs in the OS2200 environment of a ClearPath HMP IX system. It delivers HTML documents with the graphics, applet, and multimedia files stored by the 2200 operating system without requiring front-end gateway systems. Conversely, user actions (e.g., clicks, form input, and hyperlinks) can trigger transactions on the server.

Through a CGI-like interface, WebTS provides standard Web-browser access to TIP, HVTIP, and Open/OLTP distributed transactions, with full OS2200 security, via direct 2200-node input/output interfaces. WebTS also includes the JavaClient for DPS feature, described later, to enable DPS-based applications. WebTS additionally supports ASCII and Universal Compiling System (UCS) COBOL and C applications. WebTS allows transactions thus used to continue to be used in their previous roles.

WebTS can initiate Open/OLTP services locally on the OS2200 side and remotely on the ClearPath Intel node (via Tuxedo).

For applications already using the Open/OLTP HAA (heritage application access) feature, no application changes are necessary. Work required to change TIP and HVTIP applications varies, depending on the transaction’s I/O mechanisms; they must be modified to use the HTTP-based mechanism supported by WebTS. A transaction must use MCB (message control bank) to operate with WebTS.

WebTS provides Web access to DMS and RDMS databases.

WebTS supports the Windows and Unix directory and file naming conventions in addition to the OS2200 file and element naming convention.

WebTS maintains an access log and error log, recording all page, transaction, and error requests to the server. PC- and Unix-based commercial log analyzers can read and analyze the data from these logs.

A Windows PC-based monitoring interface (the WebTS Administration program) performs normal maintenance and online configuration tasks. For example, it has parameters to throttle WebTS activities, such as the number of threads or the number of concurrent communications access sessions.

WebTS can be used with Web security, such as the combination of SSL, to encrypt messages, and certificates, to authenticate both the clients and servers. SSL encrypts all messages flowing between the browser and the server. When enabled, server and client identification and authentication is done automatically and transparently at the beginning of each SSL session. Additional security outside WebTS applies as well, such as various firewall mechanisms and secure communications configurations.

Based on Java and available as a feature of WebTS, JavaClient for DPS (Display Processing System) is a conversion tool. It converts DPS-capable transactions (i.e., their screens) to be Web-browser accessible (i.e., to Java programs), usually without application modifications.

Because JavaClient for DPS actually does use Java, this allows the existing host-based applications to be enhanced with locally processed logic in the Java applet, rather than by modifying the host-based application. This is accomplished with the Form Assistant application. Through Form Assistant, backgrounds, fonts, field movement, help, buttons (potentially displayed as graphical images), and graphics, sounds, and other multimedia can be added.

When the user requests a Web page tied to one of these transactions, a Java applet is sent to the browser. This applet is effectively a Java client to the OS2200 transaction processing application, making available to the user all of the application’s functionality. Thus, the same transaction can support the existing (dumb) terminals as well as Web terminals. In this new environment, DPS accepts HTML as a new terminal type, and DPS produces HTML output referencing Java applets.

From a security standpoint, only registered transactions and registered OS2200 program files are available and accessible.

The ClearPath NX/Atlas Web Server is a Web server designed to handle the connectivity and transaction volumes of the largest enterprises. Supporting multiple individually configured Web sites, it runs in the MCP environment and communicates using HTTP over a TCP/IP network. Via the HTTP requests, the ClearPath NX/Atlas Web Server can serve up text, images, audio, video, and Java applets. It has built-in support for CGI libraries, and thereby allows an organization to develop gateways that provide access to MCP databases, applications and resources. The ClearPath NX/Atlas Web Server is intended to replace the NX/Web Server.

The ClearPath NX/Atlas Web Server is written in native, not ported, code. It has its own API written in ALGOL, called AAPI (Atlas API). Through the AAPI, applications can access MCP databases, COMS-initiated applications for transaction processing, LINC systems, system administrator and operator functions, the MCP file system, MCP security, and WFLs (work flow languages) and system utilities.

Some of the features Atlas supports include tracking how much traffic the Web site generates, transaction logs specified by Web site, error logs specified by Web site, and support for off-the-shelf log analysis tools.

An integrated MCP-based security model and system USERDATA information is the basis for the ClearPath NX/Atlas Web Server. A userid and password is required for a privileged user to access the administration Web site, its documentation and logs, the Atlas site manager, and the configuration and other private files. TCP/IP Security Services are used to restrict access to specific Web sites. HTTP basic authentication is supported.

Because mainframe attributes are only now showing up in lesser-scale client/server systems, many organizations are reluctant to abandon their industrial-strength databases; scalability, high capacity, high availability, resiliency, integrity, security and manageability still count. Therefore, providing access from the Web to the existing databases is important.

In a green-screen terminal environment, the only way to the data is through a transaction. Through Atlas, WebTS, and WebTx, Web access to these transactions is provided, and Cool ICE can provide access to the databases through Web-enabled applications.

Outside of transactions, there is a complete collection of software interfaces available for the databases. These include ODBC, JDBC, OLE DB (object linking and embedding for databases), OTG (Oracle Transparent Gateway), as well as standard SQL queries. And these can all be accessed via the Web.

On the ClearPath IX and NX systems, ODBC access to MCP DMSII and OS2200 DMS data sources from Internet servers and browser-based applications is provided by INFOAccess products. UniAccess provides access to OS2200 RDMS data sources. With these mechanisms, no changes are required to existing applications, nor are any changes required to the database schemas.

There are many types of security, including physical, network access, transmission, authentication and application security. Web security considerations focus primarily on various forms of access security, data encryption and authorization. As part of any Web server rollout, develop a security architecture that includes a firewall, intrusion detection and monitoring.

SSL, the most commonly supported security protocol on the Web, is an open standard for providing encrypted and authenticated services over the Internet. Once turned on, it uses a 40- or 128-bit session key to encrypt all traffic between the server and the client, as identified by its TCP/IP address. (Without special government permission, the use of 128-bit encryption is restricted to domestic use.) The TCP/IP addresses identify the host and client via unique addresses.

To understand SSL, you need to understand what a socket number is. In TCP/IP, it is the concatenation of the sender’s or receiver’s IP address and the port numbers of the service being used, for example, www for the World Wide Web, or ftp for file transfer protocol. The pair of these (the sender’s and receiver’s socket numbers) uniquely define the connection between the two across the entire Internet.

SSL is designed to be as transparent as possible. It is initiated with a handshaking process where: The authentication takes place, a selection of the encryption algorithm is made using public and private key encryption, the key exchange occurs, and a secure session is initiated. The negotiation process that takes place as part of selecting the encryption algorithm demonstrates how a form of "open" security is negotiated between two entities that basically do not trust each other.

SSL uses digital certificates, which are virtual documents that authenticate individuals and entities (like servers) across a network. Digital certificates are issued by a trusted independent authority, such Verisign or, perhaps, for internal use, by your own organization. Certificates are also referred to as X.509 certificates.

SSL also uses a message digest that helps protect against interception and alteration during transmission.

There are several types of firewalls, and SSL usually freely passes through a packet filtering firewall. However, a proxy server firewall, which acts like a server with respect to a client, must provide special support in the form of SSL tunneling or SOCKS (sockets).

SOCKS is an alternative for implementing VPNs (virtual private networks) and is the Internet Engineering Task Force (IETF) standard for authenticated firewall traversal (AFT). SOCKS functions as a proxy server.

Making the decision to move into electronic business, especially Web-based, is not trivial, although many organizations treat it so. As with most new technologies, consider a pilot. Furthermore, security, which historically has been considered a departmental or perhaps peripheral concern, now moves center-stage to become a core business issue. Therefore, use an electronic business and security architecture development service if not completely comfortable understanding and resolving all the issues.

The following are general guidelines for selecting the appropriate approach and the necessary components for a complete solution, dependent on the requirements and environment.

First, simple Web modernization via terminal emulation. Use this option for simple Web access to existing applications and reports. Here the terminal screen interfaces and forms are passed unchanged to Web browsers. This option requires NX/WebStation for Java for ClearPath NT-to-MCP application access, and third party Web emulation components for NT-to-OS2200 application access.

For simple Web modernization via face lifting for access to LINC applications with a GUI modernization of the terminal screen interfaces and forms, use PowerClient Web Agent for both ClearPath NT to MCP or OS2200 series. Cool ICE and/or WebTx could also be used for existing MAPPER and transaction processing applications.

When a Web application server paradigm is desired, for which ClearPath HMP open platform business applications or logic are planned, and management and security of a two- and three-tier Web application architecture is required, the Cool ICE information (application) server is the proper route. It allows the direct invocation of server commerce and business process applications as well as existing applications. The Cool ICE ClearPath architecture can be two-tier and distributed three-tier environments, depending on the requirements for the application’s isolation, performance and security.

Web-enabling transactions has the most options and requires careful consideration to determine the best approach.

For medium-to-high-volume Web access to applications and transactions on HMP IX and NX systems, use WebTx and Pathway or HTP/ic, or Cool ICE. This applies especially if transactions can be easily modified to send or receive simple input and output messages.

If complex business rules and/or electronic commerce logic are required to extend the existing transaction system, use Cool ICE on just about any platform.

If transactions occur directly on the OS2200 node, use WebTS and the OS2200-resident applications for the given transaction.

For DPS-capable transactions, use the JavaClient for DPS feature of WebTS.

If the transactions occur directly on the MCP node, use Atlas Web Server and the MCP-resident applications for the given transaction.

About the Author: Charlie Young is Director of U.S. Network Enable Solution Programs in the Global Customer Services (GCS) organization for Unisys. He can be reached at charlie.young@unisys.com

Product Executes on Also applies to

• PowerClient Web Agent NT MCP, OS2200, UnixWare
• NX/WebStation for Java Windows desktop MCP
• Open/OLTP MCP, OS2200 NT, UnixWare
• Open/OLTP Pathway UnixWare OS2200
• WebTx NT, UnixWare MCP, OS2200
• HTP/ic NT MCP, OS2200
• Cool ICE NT, UnixWare MCP, OS2200
• WebTS OS2200
• JavaClient for DPS Windows desktop OS2200
• ClearPath NX/Atlas Web Server MCP