Re: Single Page Applications -- WEB400

Brad,

You have the gist of things. But there not asking how to get IBM I data to their ASP.NET applications. They already know what they want. They want to get the data using the .NET Data Provider to run SQL against DB2 files and/or called stored procedures to kick off COBOL programs.

I was hoping to find some way our COBOL developers could avoid having to learn ASP.NET in order to become web and mobile developers. I was hoping to make an argument that CGI COBOL lets them leverage their COBOL skills, or the IBM i Integrated Web Services is so simple that COBOL developers would essentially be leveraging their COBOL skills. The main benefits (that I see) would be: (a) we can more quickly leverage COBOL developers for web and mobile development if they don't have to learn ASP.NET, and (b) we would be positioning the IBM i as a web server and not just a back-end database server.

I'm still going to make the case, but I'm less and less optimistic about selling it to managers. I think the counter-argument is, "We can use ASP.NET as we've already been doing for years. And we can split responsibilities between developers, with some COBOL developers on a team learning the browser UI and SPA side and other COBOL developers on the same team learning ASP.NET for traditional web applications and services for SPAs."

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Thursday, May 28, 2015 12:10 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications

Kelly,

Let me know if I'm oversimplifying.. but... it sounds like they're set on .Net. Lets say they are.

Then it sounds like the IBM i side of things just needs to get the data to the .Net applications (via web services, data mirroring, stored procedures, etc.. etc..)

Maybe you should be asking them "how do you want us to get the data to your .Net applications?" And then work out if it's viable on your end with COBOL.

If they want to send data selection parameters to a web service app on the IBM i that returns JSON (or XML, or something else) that should be work fine.

Brad
www.bvstools.com

On Thu, May 28, 2015 at 10:41 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

I have a proposal out to use CGI COBOL in our shop. I don't think it's
going to be accepted.

We've been running our corporate web site on ASP.NET (and accessing
the iSeries as needed) for over 12 years now. We also have a number of
custom, in-house web sites written with ASP.NET and accessing the
iSeries as needed. The question is what are we going to use to start
developing web and mobile applications instead of 5250 green screens.

The question I'm being asked is why would we want to have two ways of
developing web and mobile applications? That means we will have to
maintain two sets of legacy applications and maintain sufficient staff
with the right skills. Add that to the demonstrated success over more
than a decade at using the ASP.NET approach. So why in the world would
we want to add COBOL CGI to the mix? That's the obstacle I have to
overcome to sell a CGI COBOL approach, or an IBM i Integrated Web
Services approach, or any approach other than ASP.NET.

Our development teams are organized by lines of business. So the
browser UI and SPA developers on the client side, and the ASP.NET web
application and services developers on the server side, will actually
be on the same team. The team is responsible for end-to-end
application development for their lines of business. So pointing fingers at each other gets us nowhere.
I think that will be a non-issue for us.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Raul A
Jager W
Sent: Thursday, May 28, 2015 8:53 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications

SO, when something does not work as expected, or fais, you can bounce
blame betwenn two teams.

I think Nathan sugested using Cobol, this will be by far the best
alternative.
More reliable, less downtime, less cost, scalable, easier to develop,
easier to debug, faster, better security...

______________________________________________________________________
_ On 05/27/2015 01:02 PM, Kelly Cookson wrote:

I would suggest that client-based frameworks such as Angular JS
should not entirely replace server-based frameworks.

In fact, this appears to be where our shop is heading.

Our shop appears to be heading towards a mix of SPAs and tradition

server-side web applications using ASP.NET--with the .NET Data
Provider to access DB2 files and stored procedures on the IBM i.

And, instead of having individual COBOL developers create end-to-end

solutions, it looks like we might divide responsibilities between: (a)
coding browser UIs and SPAs on the client side, and (b) coding
traditional web applications and RESTful services on the server side.
So, in terms of web and mobile development, some of COBOL developers
would become client-side developers and some would become server-side
developers (on windows servers). It's a different approach for us than
individual developers creating the 5250 green screens and the business
logic behind them.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Wednesday, May 27, 2015 11:33 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Single Page Applications

I think you are suggesting that returning JSON data is not as safe
and efficient as returning the html itself. The latter is what you
would be doing in a traditional cgidev2 application, but we have
dumped that method (although it is still supported) in RNS 6.

Of course Brad can speak for himself, but I don't think he was

suggesting that one approach was safer or better than the other; just
that there are many alternatives for generating browser pages,
including server-based and client-based frameworks/techniques.

I would suggest that client-based frameworks such as Angular JS
should

not entirely replace server-based frameworks. You might continue to
use server-based techniques to generate HTML reports (stream files),
transform them into PDFs, and stream either format to browser clients.

You get a much more efficient process, and a much faster
development time, if you use the data model approach (basically the
JSON) with two way binding on the visual components. Now the
developer can just arrange components on the page and bind certain
elements to data model

properties.

Could you be more specific about the efficiency gains and developer

productivity? Are you suggesting that client-side tools and utilities
streamline development? If so, then how?

The model gets exchanged between the client and the server, and the
RPG part of the process is now lightweight compared to some of the
complicated
cgidev2 programs we used to have.

I understand that, because browser page (UI) generation is being
moved

from the server to the client.

Our data grid component can do page by page loading, filtering,
sorting on huge files just as easily as a green screen subfile can.

That's good, but it doesn't sound like 2-way binding. Or is it?
--
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.

-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --
--
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.

--
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.

--
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.