Re: Webfacing out, EGL in

Aaron Bartell wrote:

But let's realize one thing here. The degree of ripping and replacing is
what's important, and IBM does more retooling than necessary to meet new
technology business needs...... The issue I have with IBM's
approach is they ask you to change 50% to 60% of your application stack with
the introduction of technologies (i.e. introduce a new business language -
EGL) vs. capitalizing on RPG and just adding a new View. Now EGL wouldn't
be such a bad new thing as it provides benefit to non-iSeries customers, but
it is also being done INSTEAD OF a native framework on the IBM i that would
allow the M and C of MVC to stay in RPG vs. requiring the C to be EGL (hope
that string of sentence letters makes sense :-).

I am a little baffled as to why IBM missed the boat with something more "native" back in the mid 90's. Perhaps they didn't see the Web coming and were still fighting the OS wars with Microsoft and got lost thinking all things were going to be fat clients on Windows. I don't really know. But it is what it is at this point and I am not sure there would be a huge advantage to re-architecting a solution. Because of the way the web works, you'll have to deal with HTML, CSS and Javascript so you'll need new tools for that regardless and, you want them separate from the RPG you will use for business logic. OK. Both you and David would use open source tools for that (which I do as well, when I am not using EGL). So your "issue" with IBM is that the technology that interfaces your HTML pages and your business logic isn't RPG centric enough ? Or perhaps not i centric enough? You are straying into an area where I have little expertise (not that I do elsewhere...). I personally don't care *how* the data in my business logic tier gets mapped to the HTML and vise a versa. I just want to be insulated from the details and allowed to write business logic and design my FBU (functional but ugly) HMTL and have it work. I am a pragmatist. If it is simple and it works and allows me to deliver solutions that are stable and attractive (well, maybe I have a ways to go on the "attractiveness" part but it ain't the tool's fault), if those goals are met then I am good to go. I'd rather it ran on i and, indeed, all I develop runs on i, but I don't technically care how the details are carried out. That may be important to you but I'll learn whatever I need to stay competitive. When it comes to EGL, and I am NOT proposing EGL as a panacea here, it is easy and it works. I can integrate my View with RPG business logic and Java business logic as well and do it easily.
As to the "tearing out the stack" issue. Again, even if the 50-60% figure is somewhat accurate, if the tool makes it easy to move then I don't care how much of the application stack has to be replaced although I think the move from 5250 to "traditional" web technologies is more invasive than the move from one web technology to another. Going from 5250 to Windows fat client is equally invasive. But, even with VA RPG, there was only limited op code support for Windows (but I'll readily admit to not knowing much about it). Could you take an existing 5250 application and add a few VA RPG op codes to read and write to "windows" instead of screen formats and that is all you had to do to port a 5250 app to Windows? Again, that *sounds* like what you want for the web but I may be misunderstanding.

But you miss my point. Of course consultants are fine with technology
changing (which both of us are). We actually enjoy the challenge of trying
to make the NBT work within an existing organizations current software
family. We *can exist* because technology changes so much. We can make
good money by trying out a majority of the solutions out there and
determining what collection of tools will work best for the next 5 years.
The issue is that changing technologies significantly adds very little value
to the business. As I see it the business cares about making sure they have
easy interfaces for their customers and employees. This means that only the
user's *interface* to the server should be the only thing changing and NOT
the majority of the application stack (i.e. adding a new business/controller
language of EGL on top of RPG).

OK. So it IS the difficulty in moving from 5250 to web. Again, because the paradigm is different between a 5250 app and an web app, I am not sure how readily this could have been accomplished. Yeah, I would have thought that IBM would have developed something that was more RPG-ish for the RPG programmers but, they didn't. I don't think it will happen.

Sure they could develop a much better system for long term. They could
build the View layer once (using all the supporting technologies they used
for EGL), document the interface to that View layer and then allow it to
seamlessly talk to the varied servers they have along with the Controller
and Model code already written in the langauges on those servers.

I don't know how technically difficult doing such a thing would be. You are smarter than I on that front. It seems to me, however, that is it pretty pragmatic to select from a range of tools that can target the i as good substitute for "native" technologies. It also seems to me that regardless of how seamless the layers are, you are still going to end up with an EGL-ish mix. It may not be a meta language like EGL but even if it was DDS and RPG, that would still be a "meta" layer before the HTML, CSS and Javascript was rendered. Learning EGL so I can generate a view layer vs creating a bunch of new op codes and file attributes so that RPG and DDS can "act" like HTML, CSS and Javascript seem like equal tasks. I guess my question is: Would you expect this seamless View layer to be written in RPG and DDS (or whatever i centric languages exist)?

I get the feeling we are settling for what is popular in the general IT
marketplace vs. demanding something better from a company (IBM) that was
able to do it 20 years ago and could still do it today it their ideas were
allowed to be put into the marketplace.

Popularity and business pragmatism are sometimes indistinguishable from each other. In this case, I think that yeah, it may be popular, but that doesn't mean it is a fad. EGL is well conceived and executed and it isn't popular, but that doesn't really mean anything. I don't believe IBM is choosing popular technologies for popularity sake. It is making calculated business decisions that are targeted at benefiting the customers first and stockholders second. Sometimes they get it right, sometimes they don't, but I am thankful that they are still innovating and have kept the i in mind as they do innovate. They could have just as easily bailed on it and gone the "popular" way with Wintel.....

Aaron Bartell
http://mowyourlawn.com

On Tue, Jul 15, 2008 at 10:26 AM, Pete Helgren <Pete@xxxxxxxxxx> wrote: