RE: What style of RPG program can communicate with PHP?

Let me toss in a little opinion in this discussion.

You are reinventing the wheel, here, and by doing so, your programmers are losing the advantages that are coming from standardization.

Microsoft, IBM and others are building development tooling that abstracts away the webservice. I have a webservice running on i. All I have to do in Visual Studio is reference that service. Visual Studio imports the wsdl from that service and builds a complete proxy for it, including security asserertions. Then I use that proxy object in .Net just like it was any other .Net assembly native on my Windows machine. The same works in reverse using tools available (for free, open source) for Eclipse. However, I haven't seen any tooling yet that'll build a service program proxy for access from ILE applications.

In this tooling, the structure of the parameters is translated to XML schema that's placed in the wsdl. The XML schema is then used to build the proxy. So I just write code on the i to do some work, have the tooling build a wsdl and a webservice around it, and then anyone who wants to consume it can use the wsdl to build code to use the interface and have the work done on i just like they were having the work done on their own machine.

It has to be far less programming work than you're describing as tooling is doing so much of it for you. That tooling is possible because of standards that have been developed in the areas of wsdl and XML schema and security profiles. And all of this flows across http or any of a number of other protocols which are standards, themselves.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Friday, November 30, 2012 6:45 PM
To: Midrange Systems Technical Discussion
Subject: Re: What style of RPG program can communicate with PHP?

I have never created a web service but my understanding is that unless you write Java that the web service takes your XML coming and transforms it into PCML to pass as parameters to the RPG which puts you right back where you started.

An example where XML makes things simple. I worked on a stored procedure that processed a screen written in Java that was for invoice search. You could enter one of a two dozen criteria and any combination which was implemented as parameters so you had a program coming in with twenty some parameters. The code was a nightmare. You had to look at each parameter and see if it was used and then start building an SQL statement based on which one they entered.

With XML, you just do what I sent in the previous example. The only code that gets executed is the code for the customer and the date and it is all handled by your expat parser.

Another example might be a GUI screen where you can pick a from a list and inside each list you can then pick from another list. I had an example of this in the past but I cannot remember what is was.

With parameters I somehow have to code parameters for arrays inside of arrays and variable number of each. Now technically i could do it but it is going to be a nightmare. With XML, I just have something like:

<request>
<customer>ABC</customer>
<shipto>ABC01</shipto>
<shipto>ABC02</shipto>
<customer>DEF</customer>
<shipto>DEF01</shipto>
</request>

No guarantee as to being right. Just thrown together. The point being that I express any complex value with ease vs trying to make it fit into parameters and what is sent is elastic.

We dealt with the whole issue of 32k limits by abstracting the interface away. We built a java class that read a configuration file to determine how to communicate to the AS/400(Program, Service Program, Stored Procedure, Data Queue) and then we had mediators on the AS/400 for each type. In our case we used user spaces to send data in and back out. If I did it again I would use IFS files. To the Java programmer using the class they never even knew the AS/400 existed. You could change the configuration and in a few seconds you could be using a different method. It was just messages back and forth. The business logic was written as service programs with the same interface for everything. Performance was excellent.




On Fri, Nov 30, 2012 at 4:09 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

hi Alan,

On 11/30/2012 4:12 PM, Alan Campin wrote:

OK, but how do you parse the JSON? There are all kinds of choices
for parsing XML including built into the RPG language. Hard for me
to believe that XML has that much overhead.

Parsing (as well as transferring) XML definitely adds some overhead...
probably takes 4 times as long as straight parameter passing... but,
whether that overhead matters in the greater scheme of things really
depends on the application. In most cases, I'd say it doesn't.

I use JSON every day, and prefer it over XML. I use a JSON parser
named YAJL, which is open source and written in C. I ported it to IBM
i, and have written an RPG front-end for it. It's extremely fast. I
evaluated some of the other JSON parsers available for RPG before I
did this, but none of them performed well enough for me. YAJL was the
fastest I could find.

Some day, when I'm less burned out (sigh), I'll make my IBM i port of
YAJL available to the community, and write some articles about it.

Having said that, I'm not sure that JSON is the right option here.
One problem with JSON is that the {, }, [, and ] characters that are
so heavily used in JSON are "variant" characters in EBCDIC, so they
can be a real pain to work with in EBCDIC unless all of your data is
always in the same CCSID. In fact, a purist would say that JSON
should _always_ be UTF-8.

Now, in a web application, that's generally a non-issue, since UTF-8
is the standard encoding of the web world. But, in a stored procedure
call, you'll doubtless be using EBCDIC. I'd probably just go ahead
and use XML in that case.

Though, frankily, Alan your idea of passing XML to a stored procedure
sounds remarkably like you're reinventing the wheel... since that's
pretty much what web services do. However, using a database stored
procedure call as a transport is much more limiting (32k parameter
limit, threat of a security compromise is higher, static connection is
more susceptible to problems on imperfect network connections, etc.)

What is your objection to using web services?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.