Re: IBM i authentication and RESTful web service design

Kelly

don't explain, answer the questions

On Thu, May 21, 2015 at 10:43 PM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

Hi Henrik,

What he hasn’t told us is what he plans to put in front of such

architecture

since it doesn’t come with an UI that one way or another then has to be
coded separately and today in practice has to use a Client Javascript

Framework

such as JQuery, AngularJS or EXT JS (just to mention some).

Actually, I did mention in several messages of this thread that I'm
looking at single page apps (SPAs). SPAs are rich user interfaces that run
in a browser but feel more like desktop applications that traditional
websites. They are coded using HTML, CSS, JavaScript and (usually) some
kind of JavaScript framework like Angular.

What he also hasn’t told us is what kind of applications he plans to use
the “new” environment for. Should it be used for connecting .NET apps
to the Native Apps (integration) or is it for replacing 5250 UI’s with
browser based UI’s?

I don't see a reason to limit the potential uses of the new environment.
Services that IBM i COBOL developers create for their SPAs could also be
re-used and re-purposed by ASP.NET web applications. We would certainly
develop SPAs and services instead of developing 5250 green screens for our
IBM i users. But we could use the new environment for other things as well.
For example, services created by IBM i COBOL developers could be used in
Microsoft SharePoint SPAs (a relatively new feature of SharePoint), which
would let us develop employee self-service functions in our employee portal.

We have all a preferred environment to access IBM i applications
that may in general be divided into three categories:

Native ILE, where most frameworks are done in a combination
of SQLRPGLE and QC2LE C-modules and are a part of the Native
environment.

PASE (Java, PHP, RUBY, NodeJS etc.), that connects to the ILE
environment using SQL, Stored procedures and/or XMLSERVICE.

.NET (Microsoft frontend on Wintel), that connects to the ILE
environment using SQL, Stored procedures and/or XMLSERVICE.

I'm trying to help our shop manage software development in a two platform
shop: Windows .NET and IBM i COBOL. We've already decided not to introduce
a new language like Java or PHP into our shop. We currently do all web and
mobile development with ASP.NET. In this context, I see three main
approaches:

1. We do all web\mobile development in ASP.NET. We treat IBM i COBOL
developers and ASP.NET developers as mutually exclusive developer pools.
Developers can switch pools. But developers don’t do both COBOL development
and ASP.NET web\mobile development. Then we try to make sure each
development team has the right number of developers from each pool to
satisfy their unique demands for COBOL development and web\mobile
development.

2. We let ASP.NET developers continue to do web\mobile development with
ASP.NET. We let IBM i COBOL developers start doing web\mobile development
using single page apps (SPAs) and some kind of web serving technology on
IBM i server. SPAs provide a rich user interface developed using HTML, CSS,
JavaScript and Angular. The web serving technology on the IBM i provides a
way to pass HTTP messages between the SPAs and IBM i COBOL programs or DB2
files and procedures. The web serving technology might be implemented using
CGI, IBM i Integrated Web Services, or a custom utility as described by
Nathan in previous messages of this thread.

3. We do all web\mobile development in ASP.NET. We leverage IBM i COBOL
developers for web\mobile development by minimizing the amount of ASP.NET
that they have to learn. IBM i COBOL developers would create SPAs for user
interfaces. They would use ASP.NET and the .NET Data Provider to gain
access to COBOL programs and DB2 files on the IBM i. The IBM i COBOL
developer would not need to learn all the capabilities of VB or C#, and
they would not have to learn the .NET frameworks for traditional
server-side web applications. They would only need to know the minimal
amount of ASP.NET needed to process an HTTP request, perform SQL or call
a COBOL program on the IBM i using the .NET Data Provider, and format the
data in JSON to return as an HTTP response.

I've been seeking general strategies to deal with the general problem of
managing software development in a two-platform shop--with some additional
constraints of our shop in particular. That's why I'm coming at this from a
high level, focusing on workable architectures rather than implementation
details. I started this thread with a few questions about REST,
statelessness and authorization because I wanted to ensure the "workable"
part of "workable architectures." Things kind of grew from there.

Thanks,
Kelly

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Henrik
Rützou
Sent: Thursday, May 21, 2015 2:18 PM
To: Web Enabling the IBM i (AS/400 and IBM i)
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

Guys



We have all a preferred environment to access IBM i applications that may
in general be divided into three categories:



Native ILE, where most frameworks are done in a combination of SQLRPGLE
and QC2LE C-modules and are a part of the Native environment.



PASE (Java, PHP, RUBY, NodeJS etc.), that connects to the ILE environment
using SQL, Stored procedures and/or XMLSERVICE.



.NET (Microsoft frontend on Wintel), that connects to the ILE environment
using SQL, Stored procedures and/or XMLSERVICE.



For Kelly it would be a fairly easy choice if it wasn’t for the fact that
his Native Environment is programmed in COBOL that to my best knowledge
isn’t well supported by the various Native ILE Frameworks (Open Source or
proprietary) that already exists.



He has a separated pool of .NET programmers and COBOL programmers that
traditional doesn’t mix which in itself indicates that they are working on
separate applications. He hasn’t either told us how familiar the COBOL
programmers are working with ILE/Service Programs (QC2LE or RPGLE) and
SQLCBLLE or if any of these COBOL programmers perhaps has a little
knowledge to RPGLE/Free.



What he also hasn’t told us is what kind of applications he plans to use
the “new” environment for. Should it be used for connecting .NET apps to
the Native Apps (integration) or is it for replacing 5250 UI’s with browser
based UI’s?



What he has told us is that he wants some kind of SOA (Service Oriented
Architecture) base on some generic REST like architecture. What he hasn’t
told us is what he plans to put in front of such architecture since it
doesn’t come with an UI that one way or another then has to be coded
separately and today in practice has to use a Client Javascript Framework
such as JQuery, AngularJS or EXT JS (just to mention some).



A simple REST/CRUD may return data like this:



http://5.103.128.110:6380/pextcgidmo/wow04.pgm



While it must be UI represented like this:



http://5.103.128.110:6380/wow05.html



The biggest problem I think Kelly has is what present skills (not to
mention willingness) the COBOL pool of programmers has, since they now has
to walk into the world of UI web-development (HTML5, CCS3 and Javascript,
JSON, XML, HTTP etc.) that is quite another ballgame than making native
5250 COBOL programs. We must however assume that the poll of .NET
programmers has such skills. On the other hand they may not have skills in
the Business Applications that typical runs on IBM i and what are their
willingness to jump over that fence?



Now we are approaching a complete other angel to the problem, how to
implement new technologies in an apparently divided organization between to
technologies? From a psychological and an organizational point of view you
simply have to identify “willingness and curiosity” and “first movers” in
the organization and give them the best motivation and personal framework
of all – “success”.



Kelly has taken a very theoretical technological approach (disregarding
the organizational build) and what he really seeks is maybe how to move the
organization into a more IT efficiency/incremental innovation stack – not a
break-through innovation that doesn’t come from IT in a logistic company
but only comes from more and more efficient “on hour or minutes time
deliveries” by those that has made it their trade.



Think about that gents ;-)

On Thu, May 21, 2015 at 5:59 PM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

Thanks for the feedback and clarifications. Credibility restored :-)

Actually I haven't used the XMLSERVICE with PHP or Ruby, but
essentially what I did was put a layer above the CGI calls so the
XMLSERVICE can easily be called from a .Net application via HTTP based
function calls that are .Net friendly.

For safety sake though this or any API that accepts SQL should
typically only be used by the web app itself internally and never

exposed to the web.

Also SSL is always a good thing as well to avoid wire sniffers.

I think that's where your concern about SQL injection is definitely

valid.

I think it's good we all have different perspectives. As with
anything there is always choice no matter how we want someone to do it

our way.

Have a nice long holiday weekend. Freedom rules !!

Regards,

Richard Schoen | Director of Document Management Technologies,
HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx www.rjssoftware.com Visit me on:
Twitter | LinkedIn

-----Original Message-----

------------------------------

message: 2
date: Wed, 20 May 2015 21:08:56 -0600
from: Nathan Andelin <nandelin@xxxxxxxxx>
subject: Re: [WEB400] IBM i authentication and RESTful web service
design

Richard,

I should apologize about using the term "SQL injection" so loosely. I
know the term has a negative connotation. My point was that one
wouldn't want to provide a "service" which enabled HTTP clients (SPAs,
etc.) to send SQL statements to a server for execution. Wouldn't you

agree?

Of course ASP.NET applications send SQL statements to servers all the
time for execution, and there's nothing wrong with that. I couldn't
help but note the irony ;-)

Seriously, no offense intended in regards to your XMLSERVICE .Net

Wrapper.

I view XMLSERVICE as a valuable resource. I admit to not having looked
at your .Net wrapper, but I have studied the PHP toolkit. Would it be
a big mistake for me to assume that your .Net interface is similar?

I don't recall saying anything recently about war in Iraq, ground
water contamination, or my general unhappiness. Is that your way of
exaggerating and fabricating a position for me?
,
Your viewing me as huffing and puffing anytime I think about .Net is
humorous. I admit to having issues with Microsoft products which I
view as competitive threats against IBM i. But I mostly believe that
organizations would be better served by migrating applications from

Windows to IBM i.

Five years of professional experience dedicated to developing under
Visual ... and deploying under Windows servers, should count for some
credibility
;-)

What about 15 years experience developing hundreds of web applications
under IBM i? No?

In regards to educational opportunities at Microsoft Ignite; sorry, my
world does not revolve around Microsoft. But you already new that.
Hopefully that's okay on this list.



--
This is the Web Enabling the IBM i (AS/400 and IBM i) (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.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and IBM i) (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.