× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I use CGI. I have two Apache servers for webservices (one Kerberos and one basic authentication). Each server listens on a single port. Routes are simple, with one route per library.

HTH




-----Original Message-----
From: Kelly Cookson [mailto:KCookson@xxxxxxxxxxxx]
Sent: Saturday, June 02, 2018 2:42 PM
To: IBMi Open Source Roundtable <opensource@xxxxxxxxxxxx>
Subject: [IBMiOSS] Ports and routes needed to replace very large numbers of green screens.

Hi,

Our shop has been using .NET web pages to replace IBM i green screens. We now want our .NET web pages to use RESTful web services to connect with the IBM i, rather than using DB2 drivers and stored procedures like we have in the past. We are looking at various technologies for creating the RESTful web services on the IBM i: Node.JS, Java, PHP, COBOL CGI, and a few others. I am on a team currently evaluating our options.

My concern is with the ports and routes that will be needed to replace our green screens. Our business departments typically have 1 main green screen menu with, say, 50-150 options. A few of the menu options call up sub-menus with 5-20 options each. Each menu option calls up one or more green screens. So we have a lot of green screens in production.

If we develop web pages to replace most or all of these green screens, then I am concerned about the number of ports and routes involved. Here is how I imagine two extremes:


* One extreme is to use a unique port for every set of web pages that replaces a green screen menu option. This would result in many hundreds or even several thousand unique ports being open. This seems like a nightmare to maintain. I know too little about ports to know whether or not this would have a negative impact on system performance or security.


* Another extreme is to set up a single web server on a single port, then set up many hundreds or several thousands of routes within that single web server. This, too, seems like a nightmare to maintain. It also seems like a performance hit to have so many routes to resolve.

So,

1. Does it make sense for each department to have its own web server running on a unique port, then deal with the dozens or hundreds of routes needed for replacing that department's green screen menu options? Maybe we could keep the number of routes needed down by using single page web apps.

2. Is there a way to set up hierarchies of routes so that resolution of a particular route is quicker?

3. Could we reduce the number of ports and routes needed by running the client front-ends from web servers on the IBM i instead of using .NET? For example, if we serve web pages from an Apache web server or a Node.JS web server running on the IBM i, is there some way to reduce the number of ports and routes needed to replace so many green screens? (I don't see how, but I'm no expert so I'm asking.)

4. Does anyone have other ideas for reducing the number of ports and routes needed? And if the ports or routes can't be reduced, any ideas on how to efficiently maintain large numbers of ports and/or routes?

We will not be replacing all of our green screens all at once. It will be a gradual process of replacement. But I don't want to end up in a bad place down the road because we weren't thinking about how we use ports and routes.

Thanks,

Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<http://www.dotfoods.com>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.