Sorry if i missed this somewhere but....
Joe says "RPG programmers don't need to learn about XML or anything else.
They simply define the parameters in their function and EGL does the rest.
"
i beg to differ (i know i took this out of context however...) IMO any
RPGer that DOESN'T learn at least *some* XML is gonna be lost using *any*
of these processes. why? because *most* of them want to know what data
they are sending/receiving (i generally trap all external interface data).
again IMO you should never expose ANYTHING on your system without some
way of tracking the data. since the input/output data is in XML it's only
natural that you would want to be able to translate data being passed
*regardless* of it's format. i haven't used EGL personally but here's my
limited take on this. i simply *abhor* code generators of any type! (no
offense to those who do...you're braver than i am!) but i *will* echo
Aaron's statement, RPG *should* have native GUI capabilities *without* all
the extra gyrations, wrappers, etc. I'm sure that at least some of the
"gurus" who write the compiler *can* and should make this functionality
available! am i advocating the elimination of "green screen 5250"? not
in any sense. it would break backward compatibility. not only that i
*do* know companies that refuse to move from 5250 emulation due to the
simple speed and quick response times. for data entry purposes i still
maintain that 5250 emulation *IS* the fastest mode of data entry. does it
fit most companies model of "it ain't pretty sh*t can it" philosophy? no.
but *both* methods for UI's should be available to us without all the
hub-bub. i can't think of *any* programming model that has only one way
of implementing a UI...except RPG (yeah yeah CGI, whatever can be done but
it *should* be available via opcodes and BIFs not via service programs and
"ugly" API calls IMO).
Anyway sorry for the long diatribe but in short my opinion remains that
any and all programmers RPG or other *should* at least have a rudimentary
understanding of transporting data via XML or any other standard that
becomes a viable, useful means of data transfer method.
Thanks,
Tommy Holden
From:
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
To:
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
Date:
04/26/2008 09:43 PM
Subject:
Re: [WDSCI-L] "EGL is the easiest langauge to learn" - Joe Pluta was->
Problem updating Rational Developer for System i for SOA Construction
Aaron Bartell wrote:
I didn't put any words in your mouth. You said you had to learn a whole
new
language, and
I said it's the easiest language to learn. That's not putting words in
your
mouth.
It was the above statement that made me state you have your own ready
made
realities. No name calling, just calling it as I see it. If it helps,
it's
just my opinion :-)
It doesn't help at all. Disrespectful behavior isn't ameliorated by a
smiley. If you don't understand why saying I have my own ready made
reality is bad netiquette, then please ask someone on the list, or
perhaps a moderator. Do it again and I don't respond. This is your
last warning.
You have the app server, you have the database connection pooling, you
have
the ORM layer, you have the different JSF handlers, etc, etc, etc. Lots
of
things we already have "built in" for us with RPG. That's the stuff I
am
talking about.
Other than the app server, you're wrong on every point of this. I don't
use connection pooling, because I call RPG business logic. I use the
IBM toolbox, which is a straight socket connection, simplest thing in
the world and rock solid. I don't use ORM or JSF, because I'm not
building JSF pages - I'm using a rich web client which runs on, for
example, mobile devices.
You don't quite understand the broad capabilities of EGL. EGL can
generate Java when necessary (as when exposing a web service using
industry standards through a Java EE container). EGL can also generate
COBOL for business logic, or JavaScript for rich clients. The project
I'm working on right now uses a very thin web services layer to
communicate with a JavaScript rich client. No JSF in sight.
You seem to think I'm replacing RPG, and I have no idea where you got
that concept. Anybody who has been listening to what I've been writing
in articles and here on the list for the past ten years knows that I
promote a thin Java layer over RPG logic; the only difference is that
now you don't even need Java, you can use EGL instead. But the business
logic is still in RPG.
Maybe this question we be the better way to approach it: If we could
have
what we need to create modern UI's from RPG would you still be using
Java/EGL?
Yup. I like to use the best tool for the job. The best tool for
business logic is RPG. The best tool for complex data query is SQL.
The best tool for HTTP messaging is Java. The best tool for AJAX
clients is JavaScript.
So how exactly is EGL doing it *without* hidden fields?
It's using SOA. No pretending to be a 5250. The business logic is
just
business logic. That's the beauty of SOA.
What? That didn't answer the question at all. Look at the end HTML
code
EGL (or rather JSF) produces and you will see a plethora of hidden
fields.
Note that I don't think hidden fields are a bad thing, I am just
challenging
you on your original statement.
You've never written client/server code, have you? You see, in a
client/server environment, the server is a piece of business logic with
no user interface pieces whatsoever. It simply responds to requests.
We've done this in varying ways over the years, but the current standard
is to use messages over HTTP. the format of the messages depends on the
architceture: web services use SOAP, while more tightly coupled
conversations use JSON.
Anyway, there are no "hidden fields" because the server logic doesn't
know about the user interface. You ask it for a list of customers, or
you ask it to update an order, and it responds with the status of your
request. Since there's no 5250 interface to emulate, it's a much
cleaner design.
How much work does it take to expose an RPG program as a service using
RPG-CGI?
Depends on what you are trying to do. Do you need an industry compliant
web
service or one the conforms to a homegrown standard? Actually, either
one
can potentially take less than 30 minutes and ALL the code is in RPG.
If you're not doing industry compliant, you don't do SOAP. In fact,
most non-web service environments no longer use XML at all, instead they
use JSON, because it's more efficient. Does your RPG-XML suite do JSON?
Also, how do you code a request? Here's a very simple SOAP request:
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:q0="
http://services";
xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="
http://www.w3.org/2001/XMLSchema";
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<q0:getMySessions>
<usertoken>joepluta@xxxxxxxxxxxxxxxxx</usertoken>
</q0:getMySessions>
</soapenv:Body>
</soapenv:Envelope>
In EGL, I handle the request by writing this as an EGL service:
function getMySessions(usertoken string) returns (string)
That's all. I don't call anything to parse the XML. It's done for me.
The value is placed into the variable usertoken and away I go. I can
then call an RPG program and pass that usertoken, using a simple CALL
opcode. How many lines of code does it take in RPG? How many does it
take if they don't purchase your product?
Again, many more steps
than Java, but it didn't require a new business logic language to be
adopted
nor did it alter their Change Management strategy (i.e. still just
iSeries
objects), nor did they have to buy a bigger machine to support WAS and
instead can use the ever-solid-and-free Apache.
You still miss the point here. There's no "new business logic
language". We simply use EGL as a thin, simple procedural interface
between the industry standards of SOAP and JSON and our existing RPG
logic. RPG programmers don't need to learn about XML or anything else.
They simply define the parameters in their function and EGL does the rest.
If I understand correctly, you currenlty use WDSC to generate the WSDL
and then RPG to write the code and then your XML-Suite to actually parse
the XML. I use RDi-SOA, and I can do the whole thing from end to end.
By the way, how do you generate the response? Here's a typical response
in SOAP:
<soapenv:Envelope
xmlns:soapenc="
http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="
http://www.w3.org/2001/XMLSchema";
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Header />
<soapenv:Body>
<p632:getCountResponse xmlns:p632="
http://services";>
<return>{"count" : 373}</return>
</p632:getCountResponse>
</soapenv:Body>
</soapenv:Envelope>
This probably the simplest SOAP response you'll ever see. All I have
to do is define the return value in my function. How would you do it?
How much of this SOAP message do you have to manually type into a
template? What happens when the XML gets more complex? If your
parameters change, do you have to write a new template? Do you have to
write more or different calls to your product?
With EGL, I don't have to worry about any of this, because EGL does all
the work for me transparently. It uses the metadata that defines the
variables to generate the entire message, and the WSDL that is used to
define the message to callers.
You think Java/EGL is ok, and in the same email you state you have 30
years
experience of building these things. When are you going to realize that
not
everyone has that!?!?! When are you going to realize that there is
benefit
to staying with a single language as much as possible?!?! Note I am pro
using Java around the edges where RPG simply wont work, but to replace
RPG
with Java/EGL in an area where it CAN compete is bordering on not
understanding where your IT shops resources are and where the direction
should go to gain the most ROI.
Have you read one of my articles? Do you actually read what I post
here? Your concept of using Java "around the edges" is exactly what I'm
doing: using EGL as a thin layer around the edges. I used to use Java,
but now I use EGL. Be clear on this: I use EGL to do the stuff it's
good at (such as interfacing to web services) and I then immediately
call RPG for the business logic.
What part of this are you missing? To me, it seems you are completely
locked into a model that requires RPG and only RPG. You try to promote
RPG by itself as some sotr of better solution, like the folks that
promote SQL only, or Java only, or whatever. And if I read what you're
writing correctly, it's not really pure RPG - you're promoting RPG and
your proprietary programs (I say proprietary because I assume you don't
provide the source code for your programs).
But when you convey that EGL is going to be soooo easy
to modernize your iSeries RPG applications, I think you are mis-leading
people into something they shouldn't be entertaining until after they
have
failed to do it with RPG.
I've never said anything about using EGL to replace existing RPG! There
you go putting words in my mouth! I have consistently said to use EGL
in conjunction with RPG, thus my love of RDi-SOA, since it provides both
in a single, integrated environment.
Hopefully that helps you see better where I stand and where I believe
you
stand (correct me where I am wrong),
You're wrong about nearly every bit of where I stand. Read my articles,
Aaron. Use EGL and RPG together, as I've suggested to you for MONTHS
now. Learn how fast you can leverage your RPG skills without having to
learn Java or XML or PHP or indeed anything other than the incredibly
simple EGL syntax.
I've implemented a half dozen RPG web services in the last couple of
days for someone writing a rich client interface. The client uses no
Java, the server logic is all RPG. I haven't written a line of Java,
nor has the guy writing the client code. The entire rich client
interface is written using EGL, and I use EGL to quickly and cleanly
expose the RPG business logic as a web service, generate the WSDL and do
all the grunt work that is associated with adhering to industry standards.
So this entire multi-tiered, geographically disparate application is
written entirely in EGL and RPG. No other tools, no other third-party
products.
Joe
midrange.com
