|
Hi Henrik,
architectureWhat he hasn’t told us is what he plans to put in front of such
Frameworksince 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
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 restoredexposed to the web.
:-)
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
Also SSL is always a good thing as well to avoid wire sniffers.valid.
I think that's where your concern about SQL injection is definitely
our way.
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
agree?
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
Wrapper.
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
I view XMLSERVICE as a valuable resource. I admit to not havingWindows to IBM i.
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
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.
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
