Re: "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