Kelly,

You have sane approach, which I agree with. However, I think that over the longer haul (within 3 years) your ASP developers will be using C#, ASP.Net less and less because the standard is moving to HTML5/CSS/JS. ASP, after a trip through IIS is rendered as HTML/CSS/JS in any case. Stuff that abstracts the UI and model (GWT, ASP, PHP, and many, many others) are slowly giving way to more mainstream and current technologies that eliminate the "middle man". I'd have your Cobol folks learn HTML5/CSS/JS and skip the intermediate (and fading, IMHO) technologies like ASP.

It is always risky to predict where tooling will go, but the once derided JavaScript is nearly ubiquitous and just about every new web framework language looks a lot like JavaScript. As the browser becomes king of the app world, handling more and more heavy lifting, and HTML5 and CSS handle more and more of the UI portion, there is less and less need for "intermediate" tools and languages.

Pushing to move to HTML5/CSS/JS now, rather than later, seems a prudent course these days. But, development politics and investment in legacy Microsoft technologies does produce some drag on a more rapid move.

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 12/28/2014 12:03 PM, Kelly Cookson wrote:
Again, I appreciate the feedback. Thanks.

I'm becoming more and more convinced of a two phased approach.

Why involve Microsoft at all?
We are past the point of having the IBM i do everything for us. Some of our ERPs already run on Microsoft systems (Microsoft operating systems, SQL Server databases). SharePoint and our custom web apps also run on Microsoft systems. Along with this we have a .NET ecommerce site, and our mobile development has already started down the road of using Microsoft technologies. The IBM i runs other ERPs and some custom apps (e.g., order entry, billing). The IBM i also does our heavy data crunching in batch COBOL programs. This may not be an ideal situation, but it is where we are today--where we have to start.

Phase I
We are asking IBM i developers who code COBOL all day to also become Microsoft web developers. Remember, we want Microsoft web developers for everything mentioned above...not just for IBM i user interfaces. This is a huge leap. So we want to lean against the experience of our ecommerce developers, who have been making their .NET ecommerce web site work with files and COBOL programs on the IBM i for over a decade now. This involves using Visual Studio, HTML5, CSS3, JavaScript (including AJAX and JSON), ASP.NET C#, IIS and a .NET Data Provider--with most business logic staying in COBOL programs on the IBM i.

Phase II
Down the road, when we develop IBM i user interfaces, I hope we can drop ASP.NET C# code, IIS and the .NET Data Provider. We would have greater flexibility if we run an IBM HTTP server (or Apache) on the IBM i, and have it reverse proxy for an IBM i Node.JS server. An IBM i Node.JS server would eliminate the need for CGI in the IBM i HTTP server and would provide access to a greater number of IBM i resources than a .NET Data Provider. Any server side scripting we need to do could be accomplished using JavaScript in the Node.JS server, letting us use one scripting language on both the browser side and the server side. Our core business logic can remain in COBOL programs--as it always has been. This really isn't a hybrid approach anymore.

Phase II is why I'm so interested in Node.JS on IBM i.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Sunday, December 28, 2014 10:41 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Reverse Proxy for Node.JS on IBM i

+1 Nathan...the thing that has made a "pure" i solution so viable is
that the web frontend of most apps is HTML5/CSS/JS because it is the best overall solution that meets the variety of devices that will need to display the web page. A well designed, responsive web app will basically be HTML5/CSS/JS all of which is easily served by Apache on i.
The business logic that manages the data should naturally reside on i (why have two tiers of business logic on two platforms?). So that is where I end up scratching my head on ASP/i hybrid apps. What does ASP bring to the party that can't be efficiently handled on i?

I work in a non-IBM i shop but the heavy lifting that ASP does is more closely aligned with the MSSQL DB than anything else. Otherwise I could move the Java/PHP code we have to i. ASP has a place in a shop where MS has been the "legacy" app development provider but I have always struggled to understand why in an IBM i centric shop other web technologies displace what is already available on i.

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 12/27/2014 12:02 PM, Nathan Andelin wrote:
Kelly,

It is of course a viable alternative to distribute development and
application workloads across both Microsoft and IBM i platforms but I
also recommend against it. You under-utilize your IBM i environment.
It increase the complexity and cost of your systems. Microsoft
provides a platform for viruses and other malware. It compromises
security. Performance and stability suffer.

I promote IBM i on Power. It's sad to see application workloads move
to Microsoft.

With regards,

Nathan.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.



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.