Seagull Likes RPG Open Access for SOA
May 18, 2010 Alex Woodie
Seagull Software is developing I/O handlers for RPG Open Access that will make it easier for System i shops to integrate their i/OS applications using service oriented architecture (SOA) technologies, the software vendor says. The company, whose GUI development tools are used by some of the biggest i/OS ISVs, is taking a wait-and-see approach to using RPG OA to develop GUIs.
RPG Open Access is a new feature that IBM added with i/OS 7.1. The technology enables developers to, for the first time, entirely bypass the 5250 data stream, which has been used to generate green-screen interfaces for i/OS applications. Equipped with an I/O “handler” application that leverages the RPG OA technology, RPG programs now have a way to connect to Web browsers, mobile devices, or XML-based integration methodologies, in a native and direct way.
Two of Seagull’s competitors in the i/OS GUI generation and screen modernization market, Profound Logic and looksoftware, were the first to sign up to create the I/O handlers needed to take advantage of RPG OA. ERP software developer VAI–itself a Seagull customer–and IBM‘s Lab Services group in Rochester, Minnesota, are the only other two vendors to sign up for IBM’s RPG OA program.
While Seagull is very well known in the i/OS GUI generation business–it may be the most successful vendor in the space–the vendor does not at this point have a plan to use RPG OA in this way. Instead, it likes the technology for integrating with i/OS applications, which is another business Seagull is in.
“At a very high level, the way we view Open Access is a way to open up the IBM i for better access to SOA,” says Greg Mummah, a product manager with Seagull. “Integration with other applications on other platforms can now be achieved through a non-screen interface.”
The company has completed the first of four RPG OA stages, and has a prototype component of its LegaSuite software that allows a developer to record a transaction in an RPG application without using 5250. It works but it’s not pretty, Mummah says. “To me it’s the first step to understand how Open Access works.”
The second phase, which the company is now beginning, calls for the development of a nice GUI interface to control the integration using Seagull’s RPG OA handler. Phase three is eliminating the Java component that is currently required and maximizing the performance, Mummah says.
Phase four has not yet been scoped out entirely. One idea on the drawing board is to automatically develop RPG integration code given a WSDL (an integration component developed in Web Services Description Language). Integration with other technologies, such as PCML, could also find its way into Seagull’s RPG OA development program.
Seagull is not yet ready to announce a timeline for a delivery of an SOA integration product that leverages RPG OA. “We’re trying to gauge the market,” Mummah says. “Our ISVs we talked to expressed an interest to do it this way.”
Many of the largest ISVs in the i/OS application market, such as Manhattan Associates and Oracle‘s JD Edwards group, have adopted Seagull’s screen transformation technology, called JWalk, to create Web- and Windows-based graphical user interfaces (GUIs) from the 5250 green-screen datastream that is the native output for the vast majority of i/OS applications. Seagull was one of the first vendors to hit the market with a 5250 “screen scraper” transformation tool in the 1990s, and it maintains a very large installed base to this day.
Apparently, those ISVs who OEM JWalk from Seagull are not in a big rush to rip out the screen transformation technology and bet on RPG OA. “In general, the big customers we spoke to said they were not looking to mess with that. They don’t want to rock the boat,” Mummah says. “If 10 of them come to us and said, ‘Finally a way to create fresh new application,’ we’re going to listen to them. But so far we haven’t had that.”
Mummah sees a solid precedent in the mainframe world for using RPG OA for integration. “In the mainframe, there’s the concept of a COM area. A COM area to us is the same as a handler–a predefined hook in the OS to communicate [programmatically]. Open Access is really the same type of capability.”