System iNetwork

I have been using the Flash player as a development platform for some time and must say it is a great experience from a developer's point of view and a user's point of view. I have successfully integrated it with our iSeries box and everything!

Many of my users come to me asking why all of our applications can't look like this.

I agree with the statement that the green screen time has come and gone BUT in its defense many Internet applications can not keep up with a user who "knows the numbers" of a legacy RPG application. Definitely an interesting debate but at the end of the day what really matters to most businesses is how productive their employees can be with the tools at their disposal no matter what underlying technology is powering it.

In my neighborhood, Flash is the entertainment with the progress bar, that you watch once, the first time you visit a Web site, but every other time you look for the "skip intro" link to get past it. I knew it must be more than that. Thanks for the references.

AJAX is one more enabling technology that has captured my attention. I've attached the link on my name to a screen shot of a prototype application I'm working on. It's a model for a basic database maintenance application. The page is divided into two (2) inline frames. The upper frame contains a full record view, while the bottom frame contains a list of selected records.

AJAX comes into play for example, when focus is on the list. Pressing the Up/Down arrow keys will navigate to prior and next rows, highlighting the currently selected row as you go. Also, when a new row is selected, corresponding records are retrieved from the AS/400 and shown in the top frame.

One interesting point. Say a user holds down an arrow key. The highlight bar moves from row to row, traversing the list at a rate of about 25 rows per second, while the browser is firing off requests to the server via AJAX at the same rate. Records in the top frame fly past at a rate much faster than a human can read. It gives the user the impression that they are in control of the user interface.

Responding to keypress events in an efficient manner is one way to enhance the productivity of a user. AJAX along with streamlined browser to host communication makes that possible.

Nathan.

Nathan, thanks for those details, and Nick, could you describe more what you did with Flash as app interface to the iseries400?

Also, here's a question for both of you. When the apps you are writing perform business transactions as is typical of our RPG programs, do you have the session for each user resident or do you emulate a user session with stateless programming and resetting from where last left off?

rd

Nathan, I like the look of your protoype based on AJAX technology. For the programming that services this application are you using RPG or Java, and CGIDEV2 or WebSphere App Server?

It is nice work, however it is done.

We have already begun using Java with the Spring framework for some web apps here, and I am wondering if we should also look at the RPG+AJAX approach vs. having a Java/Spring layer wrapped around RPG applications. For some applications one approach might work better than the other, but we're just beginning to explore and evaluate our options.

To elaborate a little bit on my statements above. The integration between with the Flash player and the iSeries is achieved by using a middleware web service API written in any language of your choice. This web service API can run on the iSeries or connected via ODBC/JDBC on a separate box. Currently I am not calling RPG programs directly but simply using the iSeries as a database server for these applications. To answer your question regarding the session, I am using a stateless model being that I am simply passing SELECT statements to our production data via ODBC.

Actionscript 2.0 and 3.0 has some very powerful libraries for consuming web services in WSDL and REST format.

Honestly, I am not much of an RPG programmer but learning more and more each day. I am curious about the feasibility of developing an Actionscript 3.0 library that can parse display files and build a rich interface on the fly according to the legacy DDS. I know this has been done before with other frameworks... Seagull comes to my mind initially but it would be very nice using the Flex framework. (transitions, states etc etc) Any guru RPGer's out there think this is possible?

Wouldn't you want to generate a UI from your domain objects in the same manner as Rails, trails, grails, naked objects, etc? With these frameworks you get not only the screens but the functionality behind them. If you create screens from DDS you don't have anything other than the screens. Don't count on reusing the original RPG that runs behind those screens - RPG isn't written to be reused in that manner.

Hmmm, yeah I guess thats true. I wasn't sure if there was a way to just pass the screens input fields directly to the underlying RPG program?

Then again if you generate screens based on legacy domain objects I am sure your views are not going to be to usable right after you generate them. How do current "web enabling" products accomplish this? Are they not using the display files only the physical/logical files or both?

One attribute that I find valuable by using the Flash player is that you know how your application is going to look in ANY browser with the Flash plugin... no IE CSS hacks etc.

I didn't mean to ignore questions from Ralph and Max, but was off-line during a family vacation. I wrote the application referenced in my previous post using RPG and a native iSeries Web interface which I also wrote, and some JavaScript for handling keypress and AJAX requests.

A new instance of the RPG program is loaded for each user when the menu item is clicked, and unloaded when the Exit link is clicked (or when a period of inactivity has elapsed). Since each user is associated with a different job there's no need to restore or save session data prior to, or after handling each request.

The main point is that we're entering an era where the browser provides the look and feel of a desktop application, even though the application is hosted on a server, and most of the code runs on the server.

Nathan.

Not only can you not reuse AS400 screens or code, it seems that you can't reuse AS400 databases either. The Rails type frameworks rely on the foreign key relationships defined in the database to create the relationships between the classes it generates. Since AS400 programmers don't define relationships between tables in their databases but instead enforce those relationships in their RPG, the value of a Rails application generated from an AS400 database is less than what you'd get generating one from a real database. It can be done but who wants classes that don't relate to other classes?

After reading several whitepapers on Flash, it appears to me that Flash and AJAX are so similar that it makes me wonder whether a spirited competition will arise between the two.

Both ActionScript and JavaScript are implementations of the ECMA language specification. The backbone of both Flash and AJAX is asynchronous request processing, paired with incremental definition and updates to screen components, paired with at least some code for managing client state.

In one case, JavaScript is used to dynamically and incrementally update standard DOM components, whereas in the other case, ActionScript is used to dynamically and incrementally update an even richer set of UI components, which are proprietary.

In the case of Mozilla browsers, standard UI components adapt to the standard look of the client OS. UI components on a Mac have something of a bubble appearance, for example. I'm not sure whether Flash components adapt to the OS, or if they just have a proprietary look and feel.

One distinction seems to be that Flash components come with built-in transitional effects and other attributes, events, and methods which are more robust than standard DOM components. Flash requires an extra plug-in for the browser. Flash components are not native to the browser, so to speak.

A downside of Flash seems to be the wait time that occurs while downloading relevant definition and script files, but I've seen that with some AJAX implementations too. Perhaps it's up to the developer to expand or trim the amount of code that's downloaded to the browser, according to the requirements of the application. Perhaps it's possible for developers to go overboard with client code under either approach. With Flash there may be a temptation to use transitional effects so often that it ultimately deters from the user interface.

In both cases, the UI is smoother, richer, and more responsive to client-side events. It looks like it's possible to improve the traditional browser UI either way.

Nathan.

Also from what I'm reading in Informationweek, Flash's Actionscript is both typed and compiled and much faster and more secure than Javascript.

But Macromedia says it uses Ajax, actually out-Ajax's the browser, so I didn't see them competing, but instead competing with HTML in the browser.

Which is obviously no contest. Flash is a platform independent screen layout nearly-as-ubiquitous plugin to the ubiquitous browser.

It may just be the interface I was looking for.

Thanks for that analysis, Nathan.

rd

I read more last night about design patterns for Flash applications which are being promoted as best practices by Adobe which cast a shadow of concern in my mind. With Flash, there seems to be a tendency to download more functionality to the browser than I'm comfortable with, which leads to longer load times for applications, and causes more of a disconnect between data which is stored locally vs. data stored on the server, and requires extra code to manage state locally.

In one example of a shopping cart application, a products table was downloaded to the client, and items were added to a local representation of the shopping cart, without performing any server I/O, until checkout, when server data was "synchronized" with client data. If an item price were adjusted or a lock on inventory, or a reduction in inventory occurred in the mean time, the client wouldn't know about it until checkout.

I've never been a fan of object relational bridges, where relational data is transformed into objects, and objects are "persisted" at some point in a process, yet another design pattern suggested by Adobe was the idea of having local representations of data objects which would be synchronized with remote representations of data objects, which would ultimately be synchronized with the relational database.

I prefer design patterns where data on a client's screen is a current, accurate representation of the data on the server, without periods of disconnect.

The prototype application I referenced in my first message enables users to navigate from row to row in a list by pressing arrow keys, which triggers an update to a frame containing a full record view plus values retrieved from related tables.

Rather than following a design pattern where screen components are updated from local data sets, which were downloaded asynchronously when the application was launched, I prefer a model where each key press performs record level I/O on the server, and displays current data on the screen.

Flash offers a data grid component which could be useful in an application like that. The data grid supports the registration of functions, which can be called when users navigate from row to row using arrow keys. But the data grid component seems to carry a lot of weight in an of itself. I tested one application where holding down an arrow key moved the record pointer from row to row, but at a rate which was quite a bit slower than my AJAX prototype, and the Flash component wasn't even triggering any server I/O or performing updates to other screen areas.

Nathan M. Andelin

Nathan, How does OpenLazlo differ from Flash?

[OpenLaszlo is an open source platform for creating zero-install web applications with the user interface capabilities of desktop client software. http://www.openlaszlo.org/ ]

I visited the openlaszlo web site, and stepped through their 10 minute overview, and reviewed the sample applications. The framework is evidently an XML wrapper / pre-compiler around Adobe Flash / Flex. I got a lot of compilation errors when I tried to insert XML tags and attributes that were intuitive to me, but evidently not to the compiler developers.

Their sample applications offer a good demonstration of the "richness" of Flash components, which offer a great deal of functionality in and of themselves. I'm not sure why they feel an extra layer of abstraction is needed around Adobe MXML / ActionScript files. To each their own.

This is pretty good evidence of the need for UI widgets that offer more optional settings, states, and behaviors than standard DOM components.

I've been getting into AJAX and have to admit that it's taking quite a bit of time to write JavaScript functions and to create objects that export various attributes and methods, supporting keyboard and other types of events. In contrast, Flash / Flex offers a good collection of pre-built components that extend a developer's toolkit.

Nathan.

I did something similar a few years ago with Delphi over TCP/IP to the AS/400. It was lightweight, just an interface to calls to the /400, but I had a Detail tab for line items which brought up an overlay window for the line item detail, rather than having some detail for each line reflecting the mouse hovering position.

To me, it's put enough detail in the line so they don't need to hover, but if they want detail then give them something substantial. This is what we do with subfiles and say a 5 Display option on a line.

It is gee whiz looking, and I see desktop database apps do it, but does that kind of server call chatter scale if a whole system of apps for a whole company, business partners, and customers are making constant calls to the server as they move their mouse?

rd

I've been downloading and reading a lot of PDF files from Adobe about Flash-Flex development, which has led to a few questions. I developed a "thick" home banking client using Delphi in 1996-1997 which was obsolete the moment it was released because during the same year banks and credit unions began offering browser interfaces to accounts. I've tried to keep more abreast of Web technology since then.

Answering Ralph's question, I'd say yes - that having servers respond to key press events is going to lead to scalability concerns, where the answer is to streamline the communication interface as much as possible, and use the most efficient database access methodologies possible, which is what I've been trying to do. I need response times of about 5 milliseconds.

Right now, I develop administrative applications for K-12 Education, and one application I helped with uses about 15 tabs for various elements of student related records (demographics, schedule, attendance, grades, transcripts, etc.), where some users are allowed access to one set of tabs while other users may be restricted.

One nice thing about an HTML template interface is that if a user doesn't have authority to a particular tab, the HTML code for displaying the tab is not even output, and the program which supports the interface for the tab is not even loaded. I get the impression that Flash-Flex is an all or nothing proposition, where the entire program is downloaded to the client when requested, where client code would then determine whether to activate certain tabs for certain users or not. Is that correct?

My understanding is that references to Flash applications are embedded in tags, essentially the same as Java Applets and Microsoft ActiveX components. So how are Flash-Flex applications different than Applets or ActiveX components?

The quickie answer on ActiveX is that the Flash plugin is crossplatform (different native versions that is) while ActiveX is limited to Windows. That's why in the dot com heyday everybody and their mother was requiring IE5+. They were doing their advanced stuff in a downloaded Windows program called ActiveX. No surprise there.

However, I just came across an InfoWorld article on open source Ajax tools, and am very taken with the synopsis of the Google Web Toolkit.

from InfoWorld July 31, 2006, "Taking the Measure of Open Source AJAX Tools" by Peter Wayner:

Google Web Toolkit

Pros:
- Fascinating translation mechanism makes integration with Java simple

- Includes a wide collection of basic widgets

- Builds a full, Swing-style application in Java that runs in Javascript

Cons:
- Working in Java makes it complicated to inetgrate with other Javascript apps

end quote

I find the con to conceptually be an advantage in that it would seem to me to make it more secure from Javascript hacks.

This is actually exactly the interface I've been looking for, unless there's a catch I haven't run across yet.

rd

Wow, haven't checked this thread in a couple of days. Some good discussion going on.

Nathan, to answer your all or nothing question regarding Flex and Flash, this is not the case. Both Actionscript 2.0 and 3.0 come with a set of objects to asynchronously load separate .swf's on the fly. Therefore you do not have to download the entire applications components at initial load time. You can perform some logic in the initial download to dictate which components are needed.

Also I guess you can say .swf files are somewhat more secure being that I can't just simply trace the HTML to find the scripts but decompiling the files are somewhat easy. I believe there are some obfuscation tools out there to help with this.

The engineers at Google are brilliant, and it's good to see what they're doing. The pace of new Web technology is remarkable to me, still. The missing piece in their toolkit seems to be an Eclipse plugin, with a WYSIWYG design surface, which somebody will probably come up with at some point.

Back on the subject of Flex & Flash, I finished reading the Flex 2 Getting Started Guide, and there seems to be potential for a very good marriage between Adobe's client technology and the native iSeries interfaces that I've been working on.

If you looked at the screen shot which I referenced in my first message, you may have noticed the OnePoint logo. OnePoint is a native iSeries portal which I'm developing, which supports authentication, access, and authority for Web applications, along with a role based menuing system, and other features which I won't go into.

OnePoint activates applications in known panels, which enables users to easily swap between multiple concurrently running applications. When a new application is activated, OnePoint may also launch an instance of an RPG program, providing a means for clients to interface with the iSeries database and other native resources in a very efficient manner.

The idea is to define a new launch method in OnePoint for Flex 2 applications which activates the application in a panel and at the same time launches an instance of an RPG program which would provide DB I/O, data validation, and other services in support of the Flex 2 application.

Flex 2 offers an HTTPService component which would provide an effective means of communicating with the RPG program, through an interface which I also developed, and is known as the Web Workstation Interface, which processes HTTP Post and Get operations, and returns template based HTML (or XML) responses to HTTP clients.

Flex 2 offers data binding support between XML responses via HTTPService requests and Flex UI components, so the interface with the RPG program seems like a match made in heaven.

One advantage to this type of interface is that session support between the client and server is automatic, and the communication interface is more efficient than anything out there, which leads to high performance Web applications.

Nathan.

What else does an RPG programmer need to know to do J2EE Web Development besides ajax, javascript, Flash, Spring, jdbc and hibernate? Are those technologies sufficient for success in creating a good web app?

There are as many different ways to develop good web applications as there are stars in the heavens, Greg.

One way is EGL, a touch of Java, and RPG.

Another is JSP and RPG, again with a touch of Java. You'll need to know a lot more about the UI pieces (HTML, CSS and JavaScript) for this.

A third way is RPG-CGI. You'll need at least as much knowledge of the UI pieces as the JSP/RPG solution.

I could go on and on. What works best for you will vary.

Joe

And all that to generate a web page, which in the end is just a poor substitute for 5250 screens?

That is pathetic.

rd

Not everything on your list, Greg, will be relevant to everyone, especially Hibernate and Flash. As Joe points out, there are a wide variety of ways of choosing and mixing technologies to produce a good web or browser-based application.

There are also teams and the distribution of labor and expertise. One RPG developer may wish to focus on learning Java to write controller and data access classes, while another might wish to learn a variety of nifty UI technologies, and another may wish to focus on restructuring RPG to service an outer presentation layer while retaining valuable business logic.

And in addition to choosing and mixing the technologies, there is the importance of design, project management and testing strategies.

"And all that"?

You have to code the RPG business logic no matter what. To make a screen, you have to use SDA. EGL is simply SDA for the web. Easy to use, and much better looking. The Java plumbing bits are a few dozen lines of code that you need to write once, and the EGL team is working to make even that go away.

So this constant refrain of "oh my, the browser is too hard for li'l ol' green screen programmers" is losing any merit that it might ever have had.

With the browser, you can show images of items and PDFs of reports and spreadsheets and charts and all manner of things that you can't do with the 5250.

So, even if you insist on not learning ANY new technologies, you will be able to use the WYSIWYG stuff in EGL and still create a better interface than you can in SDA.

And if you won't even use that then you're not looking for a solution, you're looking for an excuse.

Joe

I don't have the opportunity to post throughout the day, so my post ended up following yours and I couldn't correct it or clarify until now.

In "all that" I was responding to "ajax, javascript, Flash, Spring, jdbc and hibernate", which is unbelievable. I am not referring to RPG-CGI or Java servlet-JSP wrappers.

Browsers have their place, as supplements to a desktop for things they are appropriate for, as in examples you gave. I wrote that from the beginning six years ago when I first wrote on this.

My concern is only partly the idiocy of web page as an interface because IT people have lost their bearings, and their marbles as far as I'm concerned. I think software since this became the wagon to jump on bears me out.

The other more important part is the asynch, stateless nature of HTTP web pages and the attempt to make a business quality session interface out of it.

As for my current personal project, I have decided on the Jetty servlet container with a Swing interface. On an iseries I would use one of your suggestions if I had to, but there is an impedance mismatch in that when a web page is needed, it needs to be of professional consumer-business partner production quality.

rd

I was curious to see if anyone would mention OOAD (Object-Oriented Analysis and Design). Lack of OOAD is why projects at my company go bad. Piling on more technologies doesn't help a poor design. The hundreds of programmers that work for my company use .Net and Java, Ajax, Spring, Hibernate and the whole menu of resume building technologies but, projects run long and large portions have to be rewritten because so many of the objects they develop are monolithic and lack cohesion or purpose and fail to represent a business entity thoroughly. Such projects become death marches. Who has seen this happen and been able to overcome the problem? How much upfront design do you do on projects?

It's hard for me to call HTML a language. It's a UI specification. The syntax is declarative like DDS, and a WYSIWYG designer such as Dreamweaver works well to generate page templates.

HTML is easy to learn, and if the traditional page at a time model fits the UI requirements of your application, then about the only other thing an RPG programmer needs to learn is a template API like CGIDEV2, and possibly an approach for storing and retrieving values which were submitted on prior pages, which may be needed to correctly process subsequent pages, since a single instance of a CGI program typically handles requests from multiple concurrent users.

The myriad of J2EE application servers, frameworks, configuration tools, IDE's, UI definition languages, object-relational bridges, 4GLs, etc. are the affliction of those who insist on having the option of deploying their applications across multiple server platforms.

Flash & Flex come into play when users need something more robust than the traditional page at a time model. Flex offers a fairly complete set of UI components which have a number of built-in behaviors and interfaces that provide a richer user interface than the traditional page at a time model. Anyone considering deploying an interface with Java Swing or the SWT toolkit in Eclipse should definitely consider Flash / Flex.

Most of the types of behaviors and interfaces built into Flash / Flex can also be implemented using AJAX to asynchronously and incrementally update page elements. You'll need a good handle on Javascript, the browser's document object model, and cross-browser idiosyncrasies, but this is the direction I'm headed for the moment.

The screen-shot I referenced in my first message combines a data entry frame with a list frame on a single page. It would be a pain to the user if the application rebuilt the entire list each time a record was added, changed, or deleted, particularly if the result set contained hundreds of rows. AJAX enables an asynchronous, incremental update to just one row, which occurs in a matter of milliseconds, which makes the UI ideal for both inquiry and maintenance.

Nathan.

When designing an interface that responds to keyboard events such as the one I outlined earlier, one runs the risk that users may press and hold down keys which rapidly fire off requests to the server at a high rate. In my prototype application, the rate is about twenty five (25) requests per second as the highlight bar moves from row to row in the list. If there were say ten (10) users doing the same thing at the same time, that would lead to about 250 requests per second. I think Ralph called it "chatter". Maybe a better term is "stress".

Users like that type of interaction. It gives them a feeling of control. That's one reason why PC databases became prevalent. But it challenges server architectures to support that level of interaction and to keep pace with users.

One question is whether CGI and distributed architectures like .Net and J2EE would have difficulty responding to highly interactive user interfaces like this. I think I know the answer in the case of CGI. When presented with say 250 simultaneous requests the HTTP server would probably attempt to activate about 250 instances of your program to service them and the system would come to a halt, for a while. If there happened to be a bug in the program, the HTTP server might need to be rebooted.

In the case of distributed architectures like .Net and J2EE it seems to me that the requests would be queued and funneled to the appropriate handler rather than overload the system automatically like CGI, but distributed architectures lengthen the path between the browser and database, adding layers of overhead that typically scale according to the number of application servers (server farms) you front end the database with.

What overhead? J2EE and .Net application servers ARE overhead. Vendors use the more politically correct term "middleware". And since J2EE and .Net are object oriented architectures, and writing SQL statements to fetch records is a pain, there's a tendency to implement object-relational mapping solutions, which is more overhead. Session management is overhead. The more robust the application, feature-wise, the heavier session containers become.

SQL statements are fairly resource intensive when it comes to record-level access, while object-relational mapping solutions cache data, and there may be the temptation to respond to highly interactive interfaces by pulling data from cache, but that could lead to questions about integrity in a multi-user environment when cache is not kept in sync with the real data.

It will be interesting to see how this plays out. While AJAX and rich clients like Flash / Flex make it possible to create "chatty" user interfaces, it seems to me that today's Web technologies are geared more around page at a time interfaces.

.Net even has an approach where the "view state" of a page can be tracked, IIRC, and Java Server Faces seems to be patterned after the same concept. So, will highly-interactive user interfaces catch on?

Nathan.

Nathan, in my recent research I am seeing some arguments that rich internet applications, not being page oriented as you point out in your post, are not feasible in the current HTTP-CGI page view architecture.

That is certainly a given to me, but the implications are of such a scale that traditionalist web bloggeres must tread carefully in acknowledging it.

What you come back to is my argument all along, that the persistent client session that we have with 5250 has always been required to do business processing, and that requirement didn't go away just because web pages are easy. They're easy precisely because they don't meet those requirements.

Everything hard about the architecture is trying to fake out a real, business quality, responsive client session as we have with 5250 and native I/O on the iseries400.

My point has been, the server side on the iseries400 is right; don't throw out the client session to be able to show a web page. Make the output interface-independent based on type of connection, and do it consistently internally in i5/OS from a systems standpoint.

For example, if a fake interactive session is required as part of the virtual controller to have the 5250 buffer delivered as XML for further distribution to whatever client interface is being used for that connection, then fine, it should be done and should be transparent to our programming.

Our server side procedural session programming is what is right, we just need a built-in interface-independent delivery for it.

Our strength in session processing will win out in the end. The attempts to fake that over countless hits from the mists of the cloud has resulted in a nightmarish scheme of technologies that could only make Rube Goldberg happy.

I believe that a persistent socket connection per client as we do on the iseries400 is what is needed for business processing, and rich internet applications have just made the point more obvious.

rd

We've got quite alot of experience at developing HMTL customer care web sites and flex (flash) seems to be the way forward. It's a lot easier to develop than AJAX and the resulting screens are very impressive