Hi Richard,
Our .NET developers are the ones wanting to find ways of developing web services on the IBM i. The .NET developers recommended using Node.JS on the IBM i, and there are several .NET developers on the same team as me looking at other technologies (Java, PHP, CGI, etc.) on the IBM i to develop web services. This team is actually being led by a senior .NET developer.
What's driving this is a desire to switch from .NET 4 to .NET Core. I have been told by senior .NET developers that .NET Core does not support some of the technologies they previously used to connect to the DB2400 database. (This is not a theoretical concern. They tried migrating to .NET Core and ran into problems.)
I did ask about using .NET 4 to create web services that interface with the IBM I the same way as always, then having .NET Core apps call the .NET 4 web services. They said it would work. But this was not the approach they wanted to take.
So, I'm not sure what more, exactly, I should ask our .NET developers. I'm open to suggestions.
Thanks,
Kelly Cookson
IT Project Leader
Dot Foods, Inc.
217-773-4486 ext. 12676
www.dotfoods.com<
http://www.dotfoods.com>
From: OpenSource [mailto:opensource-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Sunday, June 03, 2018 9:38 PM
To: opensource@xxxxxxxxxxxx
Subject: [EXTERNAL] Re: [IBMiOSS] Ports and routes needed to replace very large numbers of green screens
Seems to me you're definitely overthinking this.
Have you sat down with your .Net development team to talk architecture yet ? I believe I asked this question before.
If I were your .Net development team lead I would be most likely creating .Net web services that call the various IBMi services behind the scenes.
There's really no reason to do most of this outside of .Net.
For exposing services from .Net/IIS or IBMi/Apache, multiple apps/services or a single app/service with URL routes should work fine over a single HTTP/HTTPS port. Preferable port 443 or something else SSL enabled.
I don't know enough about your apps, but you might have a separate data service to replace each menu option and the services could be in any of the things you mentioned including .Net itself.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 3
date: Sat, 2 Jun 2018 19:41:57 +0000
from: Kelly Cookson <KCookson@xxxxxxxxxxxx<mailto:KCookson@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><
http://www.dotfoods.com<
http://www.dotfoods.com>>
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx<mailto:OpenSource@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/opensource<
https://lists.midrange.com/mailman/listinfo/opensource>
or email: OpenSource-request@xxxxxxxxxxxx<mailto:OpenSource-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/opensource<
https://archive.midrange.com/opensource>.
midrange.com
