Open Access Stirs Emotions

There's nothing like a good controversy to stir up emotionally charged discussions among the IBM i faithful. We're a little surprised to find just how emotionally charged some of the discussions about RPG Open Access are. It’s very much the kind of RPG enhancement we had been lobbying to get for years - even before we left IBM more than a decade ago. It was difficult for us to imagine people would think it's anything but great.

In case you didn’t hear what RPG Open Access is, we wrote about it here and here and we're sure Google can point you to many, many other places where people have discussed it -- some in at least as glowing terms as we did, others decidedly less happy about it. 

We're impressed and delighted with the things we’ve seen people (such as look software, Profound Logic and IBM Lab Services) doing with Open Access and we're looking forward to hearing about how others, including some clever programmers simplifying processes for their own in house applications, will exploit this new RPG language technology.

And we're delighted to see that so much discussion has been sparked in the community about it. Even though some don't agree with us about the value of this support, the energy and passion that the discussions make obvious is all about RPG!  And we LOVE that!

Even more good news: Yesterday we saw an indication that even executives in Rational are excited about RPG and Open Access. Take a look at the statement from Hayden Lindsey here.

One thing we want to make very clear: even though we’re big fans of RPG Open Access, we don’t think this is "the" way of all future RPG coding or even all future RPG Web applications. One size definitely does not fit all, especially in today's RPG community. Many shops have done just what we’ve been teaching them to do: modularize their RPG logic into discreet callable business functions that can be called via many techniques from many browser interfaces, in many cases enabling full Web 2.0 applications. Many have used other tools and languages oriented toward IBM i to develop Web applications and are doing amazing things with the platform.

Open Access opens up many new and exciting possibilities, but it doesn’t, by any means, replace all of the other tools, languages, products and techniques people have been using successfully for years to develop IBM i Web applications.

For many, Open Access enabled products may be the best way to get there from where they are. For many others, the discussion of using Open Access tools to get to the Web may be just the thing that spurs them to look at all of their options and to begin modernizing the user interface. Whether the best solution for your application set is based on Open Access or not, moving forward is always a good thing to do.

Comments

[Tami]

I was really surprised about the complaining of cost. As I understand it, it's roughly $500-$1500. I spent that on my last laptop! How is that prohibitive? I don't get it.

[david]

Tami, it's not the amount that's the issue ... it's the fact that there's a charge at all.

A lot of people think (myself included) that, for something like this, the runtime should be bundled into the base OS.

[Hans Boldt]

Jon, Susan: Here's the way I see it: Open Access provides a different way to call a procedure, but with a few key differences from CALL: 1) Your calls must fit into the RPG I/O model; and 2) your procedure invocation goes through a few extra layers of procedure calls under the covers.

Why the excitement? I'm not sure I understand. If it's to help web-enable existing apps, don't we already have that with WebFacing?

If it's to help code new web-enabled apps, isn't it better to design your app to fit better with the web model? That is, shouldn't apps be written from the point of view of clients making calls into the app code?

Or is the purpose of Web Access simply to generate some buzz about RPG?

As I've opined elsewhere, this leaves me rather pessimistic about RPG's future. This seems like an unfortunate diversion from what could have been done to support and improve web-enablement.

Hans

[Ron Newman]

David & Tami,

I can see both of your points of view. While I like to get things at no additional cost I can also see that $500- $1500 is not that much compared to other tools that are out there for the i system. What I do not get is all the talk about third party vendors developing ‘Handlers’ to make the Open Access product work. I was under the impression that in house developers would be able to develop these handlers for there shops on their own.
I do have a problem having to pay for the product and then pay again to get a Handler.
I may be way off base here but this is my understanding

[Ronnie]

Bundling it in the base OS was always the a big factor in supporting the i platform.

That is what gives it the edge.

Ronnie (RSA)

[Dan Devoe]

Hans,
The way I understand it, is the application handler will be able to format the data to various types of output devices -- such as a Blackberry, iPhone, web browser, or 5250 screen.

It will perform screen I/O based on the type of device -- I wouldn't be surprised if you hear "there's an app for that" pretty soon... :-)

[Aaron Bartell]

Hans,

Given your previous involvement in the RPG compiler team and the comment above, what things would you add to RPG to make it a better web language?

Aaron Bartell
http://mowyourlawn.com

[Hans Boldt]

Aaron: I would add features to make it easier to process requests and call web services.

For example, one enhancement could be to make the various protocols more transparent. That is, for any request that comes in (either HTTP, or SOAP, or XML-RPC, or whatever new comes along), the request gets translated automatically into a call to an RPG procedure, with each parameter converted appropriately.

(Actually, I think it might be possible to implement this outside of the compiler. Think of a "mod_rpg" module for Apache.)

Likewise, calling web services should be as easy as calling a procedure. Under the covers, the call could be converted into the appropriate web protocol.

(Again, this could possibly be done outside the compiler with a tool that automatically converts WSDL to a set of RPG procedures.)

A useful pre-requisite for these would be a better string data type, where string variables are simply pointers pointing into a managed string pool.

[Nathan Andelin]

The problem with comparing the cost of RPGOA to that of a PC is that you should follow-up and compare the value along with other attributes of each.

As Hans expressed, RPGOA is essentially an additional way to call programs and procedures and share data structures between the two. A PC is a complete system. On scales of capability, innovation, use, and usefulness, there would be vast ranges of differences between the two.

Someone (not me) surmised that IBM (marketing) packaged RPGOA as a separate product, and gave it a separate price, because they really don't understand what it is. It's a feature of the RPG compiler. Does it make sense to portray it as different, and more than that?

While RPGOA may play a role in communicating with contemporary devices, that role might be like the first half octave on a grand piano keyboard.

Given that RPGOA is an additional interface for evoking programs and procedures, is it worth ordering a separate product just for that? Or should we just use procedural interfaces to evoke I/O handlers directly?

-Nathan.

[Aaron Bartell]

Hans, the issue I have with the focus of your enhancements is that it is focused on the move OFF OF the IBMi. Because of my involvement with RPG-XML Suite (www.rpg-xml.com) I have been in contact with literally hundreds of RPG shops wanting to do XML web services. The beef I have is that many shops need to do web services only because RPG wasn't pursued as the modern UI layer and instead it is often offloaded to Java or .NET - THUS REQUIRING SOME PROTOCOL TO ACCESS EXISTING BUSINESS LOGIC. And that protocol is often XML.

In my opinion the only time you should be doing web services is when there is a need to communicate with a third party. The .NET developers down the hall in the same company are not a third party. Or said differently, when you control both ends of the spectrum it would be wise to NOT implement an XML transport layer to talk from the back-end system to the front end system. Keep the modern UI within RPG and you can eliminate a lot of headaches.

Not saying better XML support wouldn't be welcomed in RPG, but it is many times only warranted because of moving processing off of the IBMi.

AaronBartell.com