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