 |
|
| Esker
Corridor for Active Server v3
by Steve Broadhead Table of Contents Aims of the
Report To test how quickly a Host application can be turned into an e-commerce or e-business application with browser-based access. To gauge the complexity of this kind of procedure and the technical ability required by seeing how easy Corridor V3 is to install and setup To test the feature set and functionality of Corridor v.3 and evaluate how applicable and effective these are in a real world IT environment. To gauge how relevant Corridor V3 is as a tool for e-business by determining how closely it fits the requirements of enterprises seeking to extend their IBM mainframe & AS/400 applications into an e-business environment. INTRODUCTION: The role of the Host computer in the new “e” world A few years ago there was a wave of articles announcing the death of the mainframe.� In the years since, there has been little sign of host computers disappearing.� What they have done instead is change their job title, from mainframe to network server.� While the death of the mainframe may have been exaggerated, the terminal emulator as we know it may indeed be a thing of the past. Many believe that the old method of turning a PC into a terminal in order to access host systems is no longer appropriate, especially in a web browser environment. Instead, a new wave of products such as Esker’s Corridor for Active Server have emerged which allow client actions and host transactions to be linked by mouse-based, click ‘n’ go techniques, then queried from web applications. This removes both the need for any coding to a great extent and for any kind of terminal emulation as we know it. Yet the underlying data is – and remains – as always, on the host. Mainframes are being turned into network servers hosting Web information and services.� While the Internet has a major access role to play in the growth of e-commerce, so every company’s internal network and the host computers located upon it have significant roles to play too.� Not surprisingly, the combination of mainframes playing the role of network server, plus tools enabling mainframe data to be published on the Web and accessed by a browser is seen by many as the enabling methodology for any company looking to take advantage of e-commerce opportunities today.� Corridor for Active Server v.3 overview The complexities of host access have increased as it has evolved through the 70s, 80s and 90s.� At first, you just ran a terminal emulation program in DOS, maybe with the addition of an emulation card in a PC slot - depending on the host type - and that was PC-to-host connectivity. End of story.� If the PCs were at a remote site, then you ran the same software, connected them up to a cluster controller or equivalent and via dial-up modem, X.25 or leased line, and talked across a wide area network connection to the same mainframe. Then came LANs, which started to get complicated; multi-segmented via bridges, then routers, then switches and now a combination of all three. In the meantime, PCs themselves got more complicated.� People started to play around with network architectures, inventing and re-inventing client-server topologies; two-tier and three-tier strategies. Suddenly there was “middleware”, 3GLs, 4GLs, object oriented coding - all new ingredients in the PC-to-host connectivity recipe. And just when you thought it was safe, along came the Internet and with it the Intranet concept, web browser-based “network computers” and a whole new ball game to play on your network, LAN and WAN alike. The problem is: none of the above developments have actually entirely replaced what came before them. There are still systems around like those described above and all require, involve, or simply define PC to Host connectivity in one way or another. In recent times the plain old LAN has blossomed into the more exciting and fashionable Intranet. Web technology provides the perfect means to publish a wealth of corporate information since it offers two distinct advantages: The information is presented in the same format no matter where it comes from. The data is accessed via a common client – the web browser – no matter what platform the user has available. The “thin client” approach offered by the web browser is the ideal way to access corporate data, but many organisations fail to make all of this data available due to the difficulties involved. For instance, much of the corporate data may still reside in mainframe-based legacy systems, making it difficult to get at unless extracted, reformatted and presented in an entirely different way. So the question is, just how easily and quickly can data and applications be re-processed to take on the guise of a web browser-based application? Here we’re about to find out by putting Esker’s Corridor for Active Server v.3.0 product to the test. First things first. Corridor v.3 is neither a simple, shrink-wrap software package you can simply pick off the shelf of PC World, install and use within five minutes of breaking the seal, nor a modular set of tools which can be effectively customised to suit a specific set of requirements. It is actually both. Yes, you can be up and running with Corridor in the time it takes to install a basic word processing application. But to fully utilise every aspect of the product requires time spent familiarising yourself with the various components. Corridor v.3 is effectively a suite of products, both server and client-based, that in combination allow you to take data and applications from the IBM mainframe (3270) or AS/400 via an IP-based connection and turn them, partially or wholly, into web-based applications. Yet the data still resides in its traditional space on the Host, managed by those same traditional tools.
So, from the backroom point of view, little or nothing need change which means that data security and management policies stay in place. What does change is the appearance and usability of those old applications as they are re-engineered into web-based applications, be it for internal use, to create an external e-commerce site or any number of variations on these and other themes. What Corridor for Active Server does, then, is to translate 3270/5250 data into HTML/VBScript and integrate it – on the fly – into web applications. There are two methods of achieving this – Plug and Play Mode or Enterprise Mode, the latter using what Esker calls the Corridor Builder, an application that plugs directly into Microsoft FrontPage or Visual InterDev, for example, and autogenerates HTML/VBScript as you navigate through a mainframe application session. Behind this it is possible to add in manual scripting, should be this required. Here is where Corridor becomes either a “straight out of the box” product or a strategic product suite. Plug and play mode enables you to do just that – install that part of the software and dive straight into terminal sessions. In Plug and Play mode the terminal screens are translated as they are brought up so there is immediately a new appearance to the mainframe application. Enterprise mode, in contrast, is for developing web-based versions of those applications with a huge range of customisation and presentation options. The great thing is with Corridor that it’s not a case of either/or – you get both options.In terms of the architecture of the product, Corridor is built around a Windows NT/2000 based engine, which runs as a background service and can be run across multiple servers. This performs all the main run-time functions such as Host communications and server and client browser connections. It is also the processing engine for the translation and transmission of Host and web data. Separate to the engine is the Corridor manager, based on Microsoft’s Management Console (MMC), which can be run from any NT or 2000 based workstation with access to the same network as the “engine”.� All these components parts can be run on a single system if necessary – ideal for a test development environments, though in practice they will be distributed to enhance performance, scalability and resilience. In a typical live, development environment Corridor is used alongside a number of extra tools. These will typically include the aforementioned FrontPage (98 v1.0 or above), VBScript and/or Visual InterDev (v1.0+), as well as maybe Microsoft’s SNA Server for SNA access to the Host computers. Corridor v.3 does support IP-based TN emulation mode and SNA natively. As we’ve already mentioned, Corridor For Active Server is really a combination of components which, together, form a complete solution for re-engineering Host applications to be run from a web browser. Here we’ll take each component part in turn, describing what it is and what exactly it does, in detail. This is the real heart of the Corridor system, a transaction processing engine which Esker claims can process up to 236,000 transactions per hour, based on a set of 400 concurrent users. Importantly, the engine can not only be installed on multiple servers but can also be load balanced between them to optimise performance and reliability. Of course, if you are looking to provide Web-based access to mainframe data, reliable access is paramount, especially in an e-commerce or e-business environment. Equally important is the ability to cope with high levels of user demand, so the solution must be able to scale well. With these requirements in mind, in v.3 of Corridor For Active Server Esker has added true server load-balancing. This distributes the transaction load from the Web server among all the Corridor Engine servers in a distributed network. It is recommended for deployment when there are in excess of 500 users on a single Corridor engine. Within the load-balancing program you can assign capabilities to each server with a Corridor engine. There are five levels from lowest to highest, enabling you to deploy a mix of different server configurations and specifications and assign them according to their transaction processing capabilities. Once load balancing is enabled, if a Corridor server goes down, the balancing levels are adjusted accordingly so the user should not encounter any downtime issues. There is also dynamic load assessment built-in, so Corridor can switch sessions between Hosts if it finds that one is carrying out excessive transactions for its capabilities. Essentially there are two services in use: the Engine service which works between the Web server and the Host application, managing the active sessions and the Push Data service which allows dynamic updates of an HTML page via the integration of JAVA applets. These must be on the PC hosting the web server. With v.3 Esker has added full integration of the Corridor Engine with an LDAP database which stores all the Corridor settings, including those recorded in the Manager which are used during both “Design Time” (via Builder) and “Run Time” phases. So the LDAP database effectively sits between the Manager and the Engine.
The Manager console, under Corridor v.3 as tested, is based around MMC 1.2 version 5.0, so anyone familiar with MMC will know immediately how to use the “mechanics” of the system. For those who are unfamiliar, MMC is like Windows Explorer in operation, consisting of a left-hand window – the tree view - displaying the hierarchical structure of the “system”, in this case, Corridor For Active Server. Beneath this is a list of contactable servers – those running the Corridor Engine – beneath each of which are three basic categories or sub-nodes; Session Pools, Tools and Servers/Current Activity. A plus sign attached to any of these sub-nodes indicates there is one or more sub-level beneath, so clicking on this can expand each of the three sub-node categories and likewise for the sub-nodes that appear beneath these. In addition there is an Action drop down menu at the top of the screen that displays, at any time, a list of actions that can be performed on the object highlighted in the tree view.
Taking each of these sub-nodes in turn: Session Pools would typically be used when you want to do any of the following: Reach another Host. Access a different Host application (using different auto-logins). Use different Host logins (using different auto-logins). Define a different HTML look ‘n’ feel (using different profiles). Define specific access rights. Sessions can be set up for either AS/400 (5250) or 3270 Mainframe Hosts and there is a simple IP/user permissions box to complete which either grants or denies access accordingly. For each session there are a number of properties which can be tuned. As well as defining the Host type, you can also define the maximum/minimum number of available sessions for each pool, assign a specific “name” and port number (default usually works) to a Host, choose a Host language, screen mode (e.g. 80/132 columns) and colour (yes/no). It is also possible to set up a profile in advance which can be attached to a session, defining the properties. Also, it is possible to assign an auto-login script to a session, for auto-navigation to a specific screen. Among a number of advanced property options it is possible to restrict execution of the session to a subset of servers, thereby protecting or reserving certain servers for specific jobs, for example. For debugging and trouble-shooting it is also possible to enable a network trace of a session which creates a file containing the complete trace of that session. The software does warn that this can consume a lot of disk space! Under the Tools sub-node are a number of different options, as follows: Auto-login script Colour tables Images Hotspots Profiles
An auto-login script takes you through a series of screens automatically. So when running a session under this option, an auto-navigation script is automatically created (this can be edited afterwards) which takes the user directly to the chosen destination screen, when they next invoke a session using this auto-login script. This is not by any means a new feature but is still very useful as a means of simplifying access to the relevant screens within an often overly complex mainframe application. It is also possible to hide the intermediate screens which are automatically navigated through. Colour tables are used to create a specific colour scheme for a session, though this can both vary, and be limited, depending on the Host/emulation combination. Images are used for banners and other “decorative” features of web pages. Hotspots have been around for years in the world of Windows-based terminal emulation and have meant a variety of different things over the years. Within Corridor, Esker’s interpretation of hotspots is a screen zone identified by a character string. When the Corridor Engine recognises this string in a application Host screen, this leads to a text or image being displayed, or a script being executed. For example, an image can be automatically displayed on a function key – one feature of one of the hotspots provided by default. Within the manager you can set up the general properties of a hotspot – assign one, define its appearance and give it a specific action.� It is possible to assign a hotspots folder – a collection of hotspots – to a specific profile, which also dictates visual features such as font size, colour table used and banner image. Here it is also possible to set up default Plug and Play images and colours, emulation time-out settings and options to check boxes foe enabling the System Request key and the Attention key, should you want these to be accessible. Beneath the Server sub-node a number of options are available under Current Activity, highlighting a number of Host Session related features as follows: You can list the Corridor servers running at that time You can launch the performance monitor You can also choose to show the services running on that Corridor server For each server there is a Properties option that allows you to set the Internet Protocol Host Name (so if you can’t reach your server via DNS to get the NetBIOS name you need to change it) and load balancing capability level. Host sessions can also be viewed from here, so you can see exactly what screen, state and status a Host session is at. These can also be stopped/started and refreshed. Importantly, for the Host session you can view a great deal of user related information such as currently available sessions, check the user ID, IP address, server, screen count (number of Hosts screens viewed),� last message sent, login time, device name and session ID. This is invaluable management information in a situation where you might – for example – be monitoring a suspect user. While the primary aim with Corridor For Active Server is to create complete web-based equivalents of terminal-based, mainframe applications, in some cases it might be suitable to simply improve the basic appearance and interaction of an application. This means a user brought up on PCs and browser-based operation can treat a mainframe application just like any other mouse-oriented application. Such is the role for Plug and Play mode. What Plug and Play does is to automatically take all the screens from the Host as you navigate through a mainframe application, converts them to HTML “on the fly” and sends them to a browser through a Web server. It also automatically converts the row of command keys at the bottom of most Host applications to hot links.
An important point currently with Corridor v.3 is that Plug and Play mode doesn’t require the Builder to be loaded in order to build an active server page (ASP). All the screens and contents are automatically converted by Corridor Active Server. A limitation here is that no customisation of screen content is possible, only the background, colours, headers and footers may be changed with the profile. But this is a very fair trade-off considering the benefits of Plug and Play mode, which is essentially what we used to imagine as the full extent of “new wave” terminal emulation a few years ago, except that this does it on the fly. It is therefore ideal for experienced users who want something beyond the basic terminal screen, or – as aforementioned - for those weaned on Windows/browser based operation of PCs. To set up a session pool for Plug and Play mode you simply create the session pool entry, optionally create a new profile and/or new hotspots and assign a colour table. Once this is enabled and the server configuration cache updated – currently a slightly annoying extra action required to enable any new session – Plug and Play mode is in operation for that session. We understand that this manual cache update will be changed in future versions of the product. The Corridor Builder/Enterprise Mode In order to create fully interactive, transactional Web applications with Corridor you have to be in what Esker terms Enterprise mode. This uses the Builder and the Corridor Engine along with Microsoft’s Active Server Page technology to integrate the Web with Host applications.
The Corridor Builder plugs directly into Microsoft’s FrontPage or Visual InterDev Web design tools, as well as others such as Sybase PowerSite. So you access it via an application like FrontPage, where it is made available in the form of additional menu options. What it basically does it take data from a Host application and convert it into Active Server Pages. So you run up a terminal-based mainframe application and, screen by screen, you create the Web-based alternative. For example, you can highlight a portion of data on a mainframe terminal application screen by dragging the mouse across it, then let Builder convert it into HTML. With Builder you can specify how the Host data is to both be represented and accessed by the user. So, for example, you can change PFKey access methods into radio button mouse-click access or even hotlinks. Menus which appears on the screen as basic textual items can be converted into pull-down lists, tables or any variation on the theme of representing data, browser style. The Builder screen is split with the screen navigation path (it builds this as you move through a mainframe application) on the left and the mainframe terminal session on the right and an HTML Screen Properties box along the bottom. Every time you perform an action on the mainframe application, so Builder creates some form of navigational process on the left. So as you navigate through the mainframe application, Builder records the navigation path and then processes this path information so you can create auto-navigation of multiple, successive Host data screens, for example. But unlike Plug and Play mode, which converts on the fly, each and every time a session is run, Builder lets you create, edit and save the revised applications, hence its’ key role in Enterprise Mode. A pull-down menu provides a list of possible options, such as adding a Hyperlink, a radio group, or a dropdown box menu, for example. Or you might want to add in a hotspot, or a text box, or a Host Input Field, where a user has to manually enter a value, or choose from a multiple-choice dropdown box, for example.
This level of customisation extends to letting you program directly in ASP/VBScript and add this into the application. It means that a “Web-ised” mainframe application can literally be as simplistic or as complete as you want it to be. For example, you can create a simple but limited web version of a mainframe application in a matter of minutes but thereafter you might spend anywhere between hours and weeks editing it to create the “perfect” web application. This kind of flexibility means that the same tool can be used for “quick and dirty” internal conversions at one extreme and perfect, polished e-commerce or e-business applications for use by the outside world. One limitation is that currently there is no true standalone version of the Builder. So you cannot, for example, develop applications “off-line”, say on your laptop working from home – without the connection to the Engine, though again this is a limitation Esker is removing with the next release of the product, we understand. Corridor v.3 In use – The Harvard Library Catalogue Scenario In order to put Corridor For Active Server – and the total concept of turning terminal-based mainframe applications into Web applications – to the test we chose to remodel a real, live application. We wanted something that was in the public domain, so anyone can go and look at the original application – in this case the Harvard University Library Hollis Plus online catalogue application.
This is an IBM 3270 based application which lets you search the entire Harvard Library book collection (the library has multiple locations) for a specific book, author or details of either or both. In this sense it can be likened to using an online shopping Web site such as Amazon.com for example, so is a valid representation of what might be achieved when creating an e-commerce or e-business site. Moreover, the library has already created its own Web-based version of the application, so we had something with which to compare our efforts with those of the library. The big difference here was that we had only one week in which to learn the entire Corridor software suite and then create a Web version of the library catalogue application, which was roughly split into three days learning the software and all of two days creating the application. For the test configuration, locally we used a Windows 2000 based system running the Corridor front-end tools with the Corridor server engine on a local network server. We then dialled into the Internet via a 128Kbps ISDN connection to access the Host machine – in this case the IBM 3270 mainframe at Harvard University. We began by creating a mainframe session for the Harvard Library Host, then “walking” through the application, working out how the whole application “hung together”, so what impacted upon what, how many different actions were there available in total, what was repeated and what was unique. The aim was both to get a general feel for the application and make a few notes on exactly how we were to recreate it in web form. This revolved mainly around how we would handle each screen and the data, given the number of choices available within Corridor Builder. The aim was also – albeit slightly unrealistically – to try and use as many different features within Corridor as possible. Clearly this actually made our task – given the very limited timescales – harder, but proved to be a good test of the product, the very reason behind the test. Before loading Builder and starting to create the Web version of the library catalogue application, we first went into Plug and Play mode to navigate through it and judge just how useful and effective this very simple alternative to the terminal application might be. For a PC-oriented user, the answer was that Plug and Play presented a far friendlier (mouse-friendly for starters!) interface than the classic 3270 green-screen alternative. And the great thing about Plug and Play mode is that it requires absolutely no programming whatsoever. While it is not a substitute for a true conversion of mainframe Host application to Web application, anyone looking to instantly improve the functionality and appearance of their mainframe applications will appreciate the benefits of this mode of working. We also created an auto-login script to speed through the elementary and unnecessary screens of the Harvard Hollis Plus mainframe application. This too proved to be both very quick and easy to implement and would be very effective for the right type of user – say a regular internal user who simply wants efficient access to that mainframe data.
One of the key points which immediately strikes you about developing applications with Corridor is that, regardless of the mode being used, the basic concepts and methods are the same. So moving from Plug and Plug, through Auto-Login to Builder is fairly seamless. With Builder, we began by capturing the screens from the mainframe application that would make up the web application equivalent. This can be done very quickly, though it is important to plan ahead rather than simply “make it up as you go along”. While the latter method can still work, since you can edit everything within Builder, a more planned, constructive approach to creating an application pays dividends in time saved ultimately. Attempting to include as many different facets of Builder as possible within the application meant that, in this case, the resulting application was a little contrived, but it did show us just how flexible Corridor is. In general, the basics involved navigating through a few screens, then backtracking, taking the data we wanted from a specific screen then choosing how to present it and how to let the user “action” that screen. Often we were spoilt for choice as to whether to create a Hyperlink, a pull-down menu, a radio button select option or any of the other data entry and selection options available. In the end we primarily went for a combination of Hyperlinks, active graphics (click on the icon) and button selections. The Plug and Play version majors on radio button selections, so we were able to contrast the two approaches easily in this way. We were keen to create an application with a different look and feel to Harvard’s own Web-based version of Hollis Plus and were pleased with the very different appearance of the two applications we were quickly able to achieve, as shown below.
Within the scope of this NSS Group review of Esker’s Corridor For Active Server v.3, we set out with a number of aims in mind, many of which were not specific to the Corridor product itself. To remind you, these were: To test how quickly a Host application can be turned into an e-commerce or e-business application with browser-based access. To gauge the complexity of this kind of procedure and the technical ability required by seeing how easy Corridor V3 is to install and setup. To test the feature set and functionality of Corridor v.3 and evaluate how applicable and effective these are in a real world IT environment. To gauge how relevant Corridor V3 is as a tool for e-business by determining how closely it fits the requirements of enterprises seeking to extend their IBM mainframe & AS/400 applications into an e-business environment. So how did Corridor v.3 come out of our evaluation? First and foremost we wanted to prove that the concept of taking mainframe data and applications and turning them into web-based applications was a realistic commercial proposition. Realistic, that is, both in terms of being able to meet the levels of complexity required to carry out such an operation and in terms of being able to deliver within reasonable times scales. Here we’re talking months rather than years, weeks rather than months and days rather than weeks, compared with traditional development methodologies. At the same time, we wanted to map this whole concept onto the “e” framework, in order to look specifically at how a product such as Corridor can ease the migration of business into e-business and e-commerce. The answers, we’re pleased to report, are very positive. Having experienced the days of early DOS-based terminal emulation at the NSS, we can appreciate just what a difference Web-based access to mainframe data can make in a commercial environment especially. Taking the Harvard University Hollis Plus library catalogue application as our sample for the testing, we were surprised at just how quickly it is possible to port the application, albeit in a raw initial form, onto the Web. Within a couple of days we had a web-based working environment, primarily using the tools within Corridor, plus a few short VBScript additions lying beneath. We realise that there is a significant difference between getting a working application online and producing a polished, robust Web application, but the key point here is that we’re talking weeks not years. And we remember from the early ‘80’s when timescales for relatively minor changes to mainframe applications were quoted in terms of months and years, not days, weeks and months maximum. Here we’re not only talking about potentially improving the application itself but completely re-engineering the front-end for a new set of users – the millennium mainframe users. With respect to Corridor v.3 itself, we were especially impressed by the flexibility of the product; its ability to let you do the “quick and dirty” on the fly, or spend as little or as much time as you want creating the ultimate application. The toolset is sufficiently broad to avoid bringing in other products, though realistically there is still no alternative to using ASP/VBScript from time to time if you want certain items to be especially precise. That said, training requirements on Corridor are minimal as we ourselves proved during the week with the product. What Corridor v.3 does gives you is the option of working in many different ways. So within a company, one development team may choose to create an application in one particular way, using one sub-set of the tools available within Corridor, while another team might favour a different approach. Neither would be right or wrong but Corridor provides the flexibility to let each choose their own development methodology with no penalties incurred for preferring a specific way of working. So as a tool for extending AS/400 and 3270 mainframe applications into the “e” world, Corridor For Active Server scores highly. One of the big issues in e-business with everyone seemingly wanting to get into the market, is – unsurprisingly – speed to market. Here is where Corridor again scores highly because it lets you choose a fast-track development cycle for bringing mainframe applications onto the Internet, if that is what you need. Equally, with features such as load balancing, it offers the levels of scalability you also need to ensure that those e-commerce applications stay up and available for customers 24 hours a day. Given this depth of features and focus on the needs of the e-business and e-commerce worlds, we see Corridor v.3 as a more than useful ally to anyone looking to move their mainframe applications forward into the “e” world. This statement applies equally to corporates carrying out in-house development and for third-parties such as e-business solution providers searching for best-of-breed tools to use during development of e-business applications for their customers. With this test, Esker set out to receive the NSS Approved award and it has achieved just that. With the addition of scalability testing, should it pass, we see no reason why Corridor v.3 should not merit the Gold award, but this is for another day. Moreover, The NSS Group stamp of approval goes, not just to Esker for Corridor v.3, but equally to the whole concept of moving mainframe applications out onto the Web. The “e” world is real after all!
Contact:
Esker Europe����
|
 |
Send mail to webmaster
with questions or�
|
