Re: RPG easier/harder to use than other languages?

What you've described sounds a lot like XMLSERVICE which works great with
PHP, .Net and also Ruby and Node via wrappers calls.

As an example of no special middleware required I created a .Net call
wrapper for XMLSERVICE and I'm currently working on a .Net Core wrapper for
XMLSERVICE since IBM probably won't support .Net Core.

The good thing is as you mentioned there is no real middleware required
with a service like XMLSERVICE.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

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

message: 5
date: Fri, 7 Jul 2017 11:43:23 -0600
from: Nathan Andelin <nandelin@xxxxxxxxx>
subject: Re: RPG easier/harder to use than other languages?

The problem with stored procedures is that they have parameters and
parameters are inflexible. You can use SQL to return result sets but
what happens when you try to send large amount of data or complex data?

The answer is to switch from an ODBC interface to a web-services
interface, which has no problem with hierarchically-structured data
exchange (XML or JSON). ODBC is also too hard to secure.

Notwithstanding the foregoing, the use of stored procedures has provided a
means of retaining business logic on database servers, which is where
business logic belongs. The migration of business logic off database
servers has been a huge travesty, and a blot on the IT industry as a whole.

The idea of moving business logic off database servers dovetails with the
problems that people have expressed regarding OO languages. OO has a place,
but the use of OO for business objects was a bad use case generally, and
its overuse has become a quagmire in many organizations.

Returning to the idea of deploying web-services as an alternative to
stored procedures, the impact on mainstream language environments that run
on servers (i.e. aspx.Net, PHP, Python, Ruby, Java) would be huge. There's
essentially no need for middle-ware language environments to be involved at
all. They just add latency, bottlenecks, potential failure points,
potential security risks. They would be utterly unjustifiable.

On the client side, browsers would likely produce and consume JSON. On the
IBM i side, RPG programs would likely produce and consume JSON.


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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD