Modernization Architectures

[avrahamn@coop.co.il]

It should be able to support the old version and also the new version - seamlesly. Something similar to the conversion from RPG2 to RPG3 and from RPG3 to RPG4. What we need is RPG + SDA + DDS to run on LINUX and/or WINDOWS Native. From that point, it will be able to call PC Programs, and PC Progrms will be able to Call the Old Style Programs. Or let IBM include Graphics Native on the Iseries. OS400 Commands could be converted automaticaly to be completely GUI. Since there is no screen design in Commands, therefore a smart conversion program could make many of the command components GUI. For example: mutually exclusive options will be Radio Buttons, ETC. Therefore it would be smart for IBM to improve the command interface, and give the ability to call commands directly from RPG, also give the option to omit the necesity to code command parameters twice: once in the program and once in the command: give an option to create an object that woukd encompas a program and a command together with it.

[idaschner@pfgc.com]

One of the best products I have seen is from Linoma Software and is called aXes. This product requires no programming and allows applications to run in a browser in batch mode. It is fast and works well. It is not mentioned in the list in the article but is definitely worth a look if you have not already seen it. Linoma usually has a booth at the Common Conference.

[J.Pluta]

aXes, from Arterial Software, is covered in the article, along with a screen shot. It is an XML-based product that modifies system tables to circumvent the interactive tax. There is little information available about the technical aspects of the tool; Arterial Software insists on keeping this information secret. If the look and feel is suitable for your application and you don't mind being locked into Arterial's proprietary HTTP server, aXes is a very simple way to web-enable your screens with little additional work. Joe

[J.Pluta]

Visual Age for RPG does a lot of this. You can actually run RPG programs natively on a PC. As to the automatic conversion of commands to GUI, my guess is that's unlikely to happen anytime soon. Commands are a highly OS/400-specific interface; there's really nothing like it in the outside world. I don't know that IBM will spend a lot of time GUI-izing that particular interface. Joe

[spincode@bigpond.com]

For clarification I would like to respond to a couple of points (I am associated with Arterial Software, the company that created aXes); It is correct that aXes delivers XML to the browser. The XML however is transformed into HTML at the browser using XSLT, thus the browser renders HTML. Interface style at the browser is controlled using CSS. Consequently, all the CSS capabilities that Joe expounds are true of the aXes Terminal Server browser interface also, without the JSP. You can use any FastCGI enabled web server with aXes Terminal Server (IIS, Zeus, Apache etc.) on the host or any other platform, it does not need to be on iSeries, we have customers doing this. The aXes product also includes a FastCGI adapter for use with IBM's HTTP server on the iSeries which can be used with aXes Terminal Server instead of the supplied aXesW3 web server. Not sure how a web server that uses the HTTP protocol is proprietary? HTTP is an open published W3C standard which any web server must use. The difference is that the aXes servers are very fast and consume less resources; bandwidth, CPU, memory. You can install the aXes product and be web enabled immediately with no intervention no matter your host model. Joe's product needs an application server also. Most vendors will keep to themselves technology that gives them a competitive advantage, Arterial Software is no different. If a customer does not wish to use batch CPW it can be turned off, it is just a feature of aXes. Bob

[J.Pluta]

When I first learned about aXes, there was no mention of the FastCGI adapter, so I was talking about the aXesW3 server, which is indeed a proprietary technology. I'm glad the FastCGI adapter is available, it makes aXes a much more potent offering! Does this adapter work with both the powered by Apache and the standard IBM HTTP servers? You also note that the FastCGI adapter can be used with other web servers such as IIS. Can you also avoid the interactive tax in this configuration? If so, that would be a great boon! Just think, no WebSphere costs and no interactive tax! As to the presentation, of XML vs. HTML, I was referring to the output of the aXes product, not the eventual rendering at the browser side. The fact that the XML is then further rendered through XSLT is a little more technical than I had room to go into. XSL is a huge subject; anyone interested can start at the W3C XSL Page. Also, you say "without the JSP". JSPs are not necessarily a bad thing, Bob. With an instrusive technique like PSC/400, JSPs can be a huge advantage because they allow you to customize the screen, easily moving things around, adding extra features, and allowing you to invoke Java classes to access other data (including hidden data in the display file!). This is one of the great benefits of the JSP Model II approach. But for a technique that customizes the 5250 datastream, the more streamlined capabilities of XML and XSLT make better sense. Finally, as to the proprietary techniques you use and their advantage as trade secrets, I understand. I published a book on my architecture, but that's because PSC/400 uses no special knowledge of the operating system; it just uses standard techniques that any iSeries programmer can understand. I get the idea that your technology requires more in-depth expertise and understanding of things like the System Entry Point Table and other OS/400 system structures, and so you wouldn't want the world to learn those secrets. Thanks for adding to the information, Bob! It's always good to present the entire story. Joe

[spincode@bigpond.com]

The aXes product is no more proprietary than any other using a modern and open architecture. The FastCGI adapter supplied with aXes is required to use the aXes Terminal Server. aXesTS is itself a FastCGI application. The supplied FastCGI adapter currently works on the iSeries with the IBM HTTP server, we (or anyone else who wants to do it) need to port Apache FastCGI_mod. This is a relatively straight forward effort. On other platforms any web server with FastCGI support will work with aXes Terminal Server including Apache. The InterSession feature of aXes determines if batch CPW is used for aXes Terminal Sessions and is configurable per server instance on iSeries. If InterSession is enabled it does not matter what platform hosts web server nor where in the network the content resides. Answer to your question is yes, no WebSphere and use batch CPW via any FastCGI enabled web server platform. Additionally you can scale with combination of any web servers<->terminal servers (1-n, n-1, n-n, 1-1) on mixed platforms. Only aXesTS needed on iSeries. InterSession is the only proprietary feature of aXes and is an off/on decision that works if you need it. How, is immaterial for users. JSP needs WebSphere and Java. Cost, configuration, admin and cultural considerations are non-trivial. Let alone the grunt required to run, this is material. This is no load-n-go scenario like aXes. Bob

[J.Pluta]

However, your comments seem to indicate that you consider aXes a superior technology to JSP. I'm probably reading that wrong, because JSP technology (and particularly JSP Model II) is arguably the most productive web technology available. Products that use JSP technology can run on nearly any platform, including but not limited to WebSphere on the iSeries. They'll also run on Tomcat or any of a number of other servers. They'll work with any HTTP server on the iSeries, including the powered by Apache server (an important point, since the IBM HTTP server is sunsetted). You're right, aXes is a plug-and-go technology. However, you can only go as far as the aXes technology allows. And as long as your business goals will never exceed the capabilities of aXes, it's a great solution. But with a JSP solution, you will learn to modify and extend your architecture using the number one Open Source web technology in the world, namely J2EE. For example, as I pointed out in the article, servlets are a natural stepping stone to portlets, which is the next major revolution in user interface design. Since aXes does not use Java technology, I don't think it will fit well into the portlet architecture. You will also open up your application to the great number of J2EE support architectures available, from Struts to Hibernate. You of course are familiar with Open Source solutions, since the FastCGI interface is Open Source. In fact, anyone who is interested in a good look at one of the fundamental components of aXes should go to the FastCGI website. It's got a wealth of information, although some of it is a bit dated. So, as always, the decision is a business decision. For short-term, easy conversions a tool like aXes is great, just as are any of the screen scraper technologies. Meanwhile J2EE requires a little more upfront investment, but that investment garners a great return in actually setting a foundation for future development. The choice in this case is short-term solution vs. long-term growth. And note that I'm not saying that J2EE means my product. PSC/400 is only one possible J2EE approach. It is a specific solution for a specific business goal: overnight web enablement of legacy systems with an eye towards full J2EE implementation. But I am saying that the JSP Model II architecture is the best way to go for long-term architectural development. But this is not new; I've been saying that for five years, long before I had a product for sale. Just go back and read my articles, or my book. Joe (Proud New Papa of Anthony Joseph) Pluta

[spincode@bigpond.com]

Currently i$eries-Java is the only main stream choice if you need application server capability, no matter brand/flavor, most do not. iSeries platform needs more choices. Why can I not use .NET (ASP.NET ADO.NET C# VB etc.) natively on iSeries? This would give additional benefits and interoperate with any CLI language (too many to name, how about RPG.NET or COBOL.NET ?). This is real choice. aXes was specifically developed to address SME requirements that currently have Hobson's choice. Let users choose, not IBM. Bob

[J.Pluta]

The primary reason we cannot use .NET on the iSeries is because Microsoft doesn't support it. But of course that begs the question - why would anyone WANT to use .NET on the iSeries? The iSeries already has two of the best architectures on the planet: OS/400 and Java. .NET is great for the thick client market, but as a server architecture it ties you to Microsoft's proprietary CLR, whereas Java solutions will run on any platform with a JVM. I hadn't planned to turn this into an operating platform debate, but if you'd like to compare Java vs. .NET, I think you'll have a great forum here to do so. Please, tell me the top 10 ways in which .NET is superior to Java. While you're writing those up, feel free to review 101 reasons why Java is better than .NET. (My favorite? "3 things a Microsoft shop can't avoid: Death, Taxes and License 6.") Joe (Proud Papa of Anthony Joseph) Pluta P.S. My middle initial is "D" for Dominic, why?