|
The following is *purely* opinion and I am not looking to start a war.
The technology stack you are implementing will have you pulling out
your hair in a couple years. Why? Because there are too many moving
parts and that will complicate many things: initial learning, testing,
deployment, long-term maintenance, upgrading machines, etc.
This is the approach shops were taking 5 to 10 years ago when IBM i
lacked a lot on the web front. That isn't the case anymore and now
the trend (read competitive advantage) is lessening the layers and
moving things back to IBM i.
There is absolutely zero reason to implement ASP.NET in this scenario.
Would be MUCH better to go the PHP/Ruby/Node.js on IBM i route.
*>I agree performance may be an issue with the XML extensions.*
If you are talking about the itoolkit.js (xmlservice interface for
Node.js) then I would breathe a sigh of relief. It is fast. (or at
least fast enough). There are two modes you can communicate with your
existing COBOL... 1) over HTTP which is good if your Node.js isn't on
the same server 2) through a generic DB2 stored procedure offered by XMLSERVICE.
The itoolkit.js decision is peanuts compared to the ASP.NET one you
are considering.
Ok, I will step down from my high horse :-)
Aaron Bartell
On Fri, Dec 26, 2014 at 1:39 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:
IBM i
Hi Kevin,
Starting sometime next year, we will be developing browser
interfaces to our IBM i. We will be using Microsoft ASP.NET running
on IIS web servers on windows. We will connect the browser pages to
the IBM i using web services (built with a .NET Data Provider that
can access IBM i DB2 files and COBOL and CL programs via stored
procedures). Our ecommerce team already does this--which is why we are starting down the same road.
Once we get our COBOL developers up and running with ASP.NET and web
services, I would like to expand our capabilities with Node.JS on
the
. JavaScript will be one of the languages our COBOL developers will
have learned as part of .NET web development. So we should be able
to use Node.JS to create web services that can access a wider
variety of IBM i resources than a .NET Data Provider--plus be using
one language
(JavaScript) in the browser and in the web services.
I agree performance may be an issue with the XML extensions. I'm
wait and see about that. However, our browser interfaces would
probably be used by no more than several hundred to a few thousand
concurrent users. I don't think we will be taxing the scalability of any of the tools mentioned.
I want to learn about reverse proxies is because it might be
possible to run IIS on a windows machine that proxies a Node.JS web
server on the IBM i. This would allow us to access our .NET Data
Provider web services and our Node.JS web services on the same IIS
server. If we don't have a need for any .NET code in a particular
app, we could bypass the IIS server altogether and instead use the IBM i HTTP server as a reverse proxy.
We are a COBOL shop and will continue to use COBOL for business
logic (when needed) on the back end.
Thanks,
Kelly
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
