Openness Undoes the RPG Paradigm

The push toward open systems is a direct response to the fact that many commercial IT customers felt trapped. They were tied to specific vendor and hardware platforms whether they wanted them or not. Worse yet, software vendors who wrote applications became committed to specific hardware platforms, whether their customer wanted them or not. This has resulted in lost sales and opportunities because customers wanted to choose hardware platforms based on their own strategies, and partners wanted to offer their application software on the platform of choice for customers.

The norm in the early 1980s, within commercial computing, was to use a proprietary system of some sort: Wang, Data General-AOS, HP-MPE, DEC-VAX, S/36 or AS/400. Portability, interoperability and openness were foreign concepts. They were “trapped” on the platform, and faced big problems when dealing with expansions, mergers, acquisitions and enterprise application integration. Business was pushing toward openness.

Initially, many customers and partners alike felt that the solution to openness would be portability. Portability seemed to mean the C programming language coupled with the Unix operating system. Portability would simply mean that if a customer desired a solution on a different platform, they could pick up the source code and recompile it somewhere else. Sounds nice, but in truth, it never really worked that way for any applications written in the 80s. Why?

Let me assert several principles, call them Mark’s Application Development Rules.

Rule #1. Software works best on its mother platform.

If you follow this principle, it means that code originally written for an AS/400 will not work as well on some other platform. Similarly, a direct port of say, DOS code to Windows 2000 will be trouble. This nasty effect is broken only once the application is written to a platform-neutral “mother architecture.” This is the clue to why openness is not just simply a matter of porting.

Openness is a matter of breaking up the application into a minimum of three distinct components where access and usage of the components is permitted through open software interfacesso called “open standards.” The components must be available or portable across platforms. The acceptance of these open standard interfaces allows for the interchange of their hardware engines and software vendor specifics.

Data

Today, the user wants the flexibility to place their data on any hardware platform within their IT organization. This data should be accessible from any approved application, user and location, with appropriate reliability, security and integrity. Furthermore, there is a general corporate goal to obtain a “single version of the truth”eliminating data redundancies, synchronization problems, integrity issues and multiple definitions.

The standard for databases today is a relational, SQL-compliant model. The optimization of this database comes from appropriate database design and utilization of important functions such as referential integrity, triggers, stored procedures, two-phased commits etc. Full usage of RDBMS saves enormous programming and maintenance efforts and increases the integrity and reliability of associated applications.

Access to the database comes from open standards, which are independent of hardware or software vendor. This data access middleware, which makes a database open, includes SQL CLI (Call Level Interface), ODBC (Microsoft’s Open Database Connectivity), JDBC (Java Database Connectivity), and OLEDB (Microsoft’s Object Linking and Embedding Database).

An AS/400 customer will soon realize that all they need from a data perspective is right under their noses. It is DB2 UDB for the AS/400. It provides the customer every aspect of data management needed. Unix or Windows NT customers have to select and procure such an offering separately (DB2, Oracle, SQL Server, etc.). The only thing you need to do is educate yourself, and put in place the appropriate plans to use and exploit what you already have.

The full use of the DB2 UDB for the AS/400 is independent of the programming languages chosen. So, RPG applications today and in the future can easily access such well-defined data. But to re-engineer an RPG existing application to fully exploit DB2 UDB, even if it will continue to be RPG, will mean significant “untangling” of data and process.

Rule #2: Your database is your key strategic IT asset. Design it well, exploit its features and carefully engineer access to it.

Process Logic

Process logic defines what happens in case of a user event or data condition. Simply speaking, this is programming to define a logical unit of work. Today, we try to separate this code from the data, user interface, infrastructure and underlying communications. It now defines a singular business process. This can relate directly back to an object-based business model (such as an entity relationship diagram). Because the process logic is independent of data, the logic becomes highly reusable in other and similar situations. In object-oriented terms, this is called “polymorphism.” In actual fact, it ends the old-fashioned practice of copying source code (resulting in inflated lines-of-code counts) and starts the process of reuse of software business components.

Where does the process logic execute, on the client or on the server? That is up to the application designer. This is a fairly serious architectural decision as it heavily impacts performance, usability, security and data integrity. What programming language is used to define the transaction is open for debate, and we’ll address this later on.

Older generation 3GL languages such as RPG have morphed themselves into being capable of delivering open/standalone, reusable business logic that is independent of the user interface and database server. This is a complement of ILE, the Integrated Language Environment of the AS/400.

What has become more interesting is the design, use, and reuse of transaction/process logic that is portable across business application and business boundaries. These should be developed to be platform neutral (the big thrust behind Enterprise JavaBeans), and designed so that future applications need to use only code and may be built up from software components that come from a variety of sources.

Rule #3. Some day you will be assembling applications from components.

User Interface

This is simple. Nobody procedurally programs a commercial GUI any more, whether client/server, Web, Microsoft or Network Station. A user interface is designed and the code to reflect this user interface is either generated by a tool or interpreted by a run-time environment.

In fact, the user interfaces themselves are considered to be “forms,” and directly reflect a type of common business object everyone understands. No one uses programming languages to create these: People use “visual” tools to define such forms. Often, especially in the Web environment, programmers are more accurately graphic designers. Programming skills are not required for user interfaces anymore.

When there is no programming logic associated with the interface, the future tells us that almost any tools will do, for example, Flash, MS Word, Lotus Notes or Excel.

When programming logic (process) is involved, you go to another type of tool that incorporates a scripting language that defines the actions to be taken for particular events. Because an event is something like a mouse click, we often refer to this type of environment as “Event Driven Programming.” The relationship between visual tools and development language is often self-evident:

Why Does this Undo RPG?

The trend toward decomposition of applications into three layers, coupled with open middleware does not blend well with the monolithic model of RPG. For RPG, all components of the application are intertwined in the program itself. There is no separation, no middleware and especially no way to move the entire system to any other platform with the same effects. There is no polymorphism, inheritance and other characteristics of object-oriented programming. The best we can do is to have “structured” programs.

Thus, any true effort to modernize an existing RPG application will eventually involve a lengthy, tedious job of untangling data, logic and user interface, even if you use RPG in a client/server or Web format for the new and modernized version.

E-Business, Collaboration, and Business Intelligence: RPG No-Can-Do

The new types of applications in vogue today carry new technological baggage. E-business applications do not work well unless they propagate the advanced graphics of Flash, the platform independence of Java, the Web standards of HTML and the advanced data/graphics interaction of XML. Nor do they perform well if e-business transactions lose their integrity because of network problems. They can’t possibly fulfill their promise if authentication, secure sockets or encryption are not included in their development. The programming to provide proper, secure bank transactions over the Internet is nightmarish. Why bother if you have Net.Commerce, Net.Data and WebSphere?

Programming collaborative applicationsones that use loosely associated data, messaging primitives, involving workflow and data synchronizationis incredibly difficult. Why bother with RPG if you have Domino?

Business Intelligence calls for altogether new computing models using Online Analytical Processing (OLAP) and not OLTP. This calls for nifty things such as data extraction, data transformation, data propagation, data cleaning, metadata, star schemas and data refining. Have you tried this with RPG lately?

The point here is that RPG performed well to help deliver commercial OLTP and batch solutions. Today’s new applications, however, are different in nature, and require a new set of tools.

Rule # 5. You don’t have to rewrite perfectly good RPG applications using the latest tool: You’re supposed to evaluate new application requirements against the tools best suited for them.

Chances are, Domino would make a lousy order entry replacement for your 5250 systems used by the order clerks today. What about the help desk, the sales tracking system, or the e-commerce system?

AS/400 Hardware Trends: the Nasty Reality of Interactive Feature Cards

We note that in the olden days, the entire AS/400 computer system, from the hardware up, was designed to run RPG. Now, you actually get punished for doing so. Today, the hardware inside an AS/400 has much more in common with other IBM systems—some sources say up to 85 percent commonality. This includes processors, system enclosure, power supply, fans and internal disks.At some point in the near future, the entire system may be shared across IBM servers (RS/AS). It would be stretching the truth very thin to claim the AS/400 hardware today is geared to RPG applications. Similarly, all that is new with the operating system (OS/400) is geared to e-business and standards. Look at V4R4 enhancements for TCP/IP, HTTP, Client Access, Integrated Netfinity Servers, Domino, VPN, etc. How much proportionally is being spent on 5250 interfaces and RPG?

IBM seems more interested in investing to punish AS/400 users for using RPG and 5250 interactive applications. Yes, the Interactive Feature Cards (as they are known on the AS/400) are a chargeable necessity if you want to use your AS/400 for anything more than the minimum number of interactive CPW cycles (CPW, or Commercial Processing Workload is a sort of horsepower measurement of the AS/400 relative performance capability). Using a single such CPW for a 5250 (Native/Interactive) function will cost more than four times as much as using it for open systems functions.

Rule # 6. You don’t get rewarded for going “native.”

Procedural Programming Gives Way

Application development using components is evolving in much the same manner as procedural code evolved, albeit at a more accelerated pace. Where procedural code, linear code written line by line, took 40 years to evolve, the component-based industry is relatively newcertainly less than five years old.What do we mean by procedural code, and what do we mean by component-based development?

Procedural Development: the Old Way…

Procedural code evolved from basic machine languages to second-generation language (2GLs) such as Basic Assembler Language (BAL), to third-generation languages (3GLs) such as Common Business Oriented Language (COBOL), to 4GLs such as Progress and many other variations of advanced development tools. Many of these advanced development tools used what were called components, but these components were essentially pieces of procedural or linear code held in procedural libraries.

Model-based application development tools ask you to model your data and business processes using their own or, in some cases, a third party’s modeling tool and they would generate the application for you.

These advanced tools were, and will remain, very powerful application development environments that will continue to save time and money in development. Unfortunately, they tend to be proprietary. You have to wait for them to evolve before you can take advantage of new technology introductions such as graphical user interfaces and Internet enablement, just to mention a couple of the more obvious and painful ones. In fact, it is still relatively common to hear stories of IT environments that have yet to move in these directions because they are being held up (some would say held hostage) by tool vendors.

Component-Based Development

Components can be defined in many ways and can even be used to describe common procedural subroutines or copied code. But for the purposes of this discussion, we are going to define components as those that subscribe to object-oriented technology. These components may be pure object technology, or in fact, procedural code “wrapped” to appear as object-oriented.

How do you tell the difference? Just ask yourself: Can the object be modified using traditional object-oriented techniques (true OO), or do you use the object as is (a sure sign of wrapped procedural code)?

Another aspect we must consider is just what a component is—more specifically we now want to focus on business components.

What is a business component? These are elements business people recognize as being important to their business. It can be a basic object such as “person” that can be further subdivided into “customer” or “supplier” or “employee.” It can be a more sophisticated object such as the common business object “address.” What’s sophisticated about address? Consider: Is it a mailing address or physical location? Is it a single location or does the business have many locations? Where does the postal code fit? This depends on where you are in the world; it may be at the end, the beginning or the middle of an address.

Doing business over the Internet on a worldwide basis makes all of this painfully important and highlights the limitations of our current application portfolio. A business component may be very large, typically called a business process component such as “invoice” or “payment” or “back order.” These very large components are made up of basic objects, common business objects and even other business components. Another characteristic of business components is that they must work together and interoperate with infrastructure components.

Why Object Oriented Now?

Object Oriented Programming was developed back in the mid-1970s. You may ask: If it’s so great, why doesn't everyone use it today? What if everyone used it today? How would the world be different? Object technology is highly flexible, adaptable and easier to maintain. It’s also difficult to get it right the first time and was initially very expensive to redesign and rework existing applications. Not to mention the enormous compute power (by 1970 standards) that it took to run object-oriented applications.

Timing is everything. Like many technologies, the compute power, technical infrastructure (operating systems and middleware) and basic agreements among interested parties (standards, both agreed to and defacto) were not there yet. They are today.

With Y2K still fresh in our memories, “So what?” would have meant literally billions of dollars that businesses might have saved or redirected to more profitable pursuits. Using object technology, we could have modified the single date object in our application system and it would have essentially been recognized by all the applications using it.

A Case for Openness on the Server Side

Standards are important, both official and defacto. Standards foster interoperability. Look how Microsoft has provided on the client a set of easy-to-use components that have given programmers an ease-of-use we only dreamed of 25 years ago. Client-side developers around the world almost universally accept Microsoft components.

Unfortunately, the server side of the equation is not so well ordered. There is such a mix of environments that even if you were fortunate enough to have a single IT vendor, chances are they would have a mix of incompatible hardware, operating systems and middleware.

Java, introduced about five years ago, has enjoyed dramatic acceptance by developers and product vendors. Why? It is both a language and an environment that delivers on the promise of running application across a variety of platforms. While we did have middleware, remember: True portability is only attainable once the application is written to a “mother architecture” that is platform neutral.This is Java!

Java gives a sense of openness that has become a rallying point for many application developers. Java is an excellent object-oriented programming language. It has the best features of Smalltalk and C++, but minimizes the problems of those languages. In rapid succession came JavaBeans and Enterprise JavaBeans.

JavaBeans provide a standard way of describing objects that, in turn, allowed tool vendorsprimarily advanced procedural tool vendorswith a way to use these objects and deliver more interoperability. A JavaBean component industry was born that brought about easier development and modification.

The Enterprise JavaBean initiative is no less important because it provides a common interface to object services—the middleware needed to access any platform-independent business processes. Application developers and tool vendors not only can mix and match JavaBean components from various vendors, they are now able to mix and match the middleware services that best suit their needs, without sacrificing the portability that Java delivered.

Who are the component developers and tool vendor?

The good news is that they are for the most part the same people who brought you the predecessors, the middleware, and the advanced application development tools. If you made a commitment to advanced development tools, then ask your vendor about object technology and Java. Some already have products in the market, others are in development, and still others are developing plans to migrate to this technology whose time has come. If you are considering moving to an advanced technology tool, a word of caution: Make sure you choose a vendor committed to openness. You don't want to be trapped with a commitment to a single tool vendor for all your application development support.

One of the leading vendors in building common business object and business process components is IBM. IBM has a deep understanding of object technology and has been introducing it into its operating systems and middleware for many years, and OS/400 may be the best example of this. It has also been a leader in the development of business object and business process components. The San Francisco project is probably the best example of this commitment, with over five years of development experience invested.

Ultimately it is you, and you alone, that must make the choice to embrace the future. If you do move forward, we offer you these tips to prepare yourself for the future of application development.

1.Understand the importance of separating database elements from the existing application. Build an enterprisewide data model that exploits the full features of your SQL compliant RDBMS. Provide access to this data via commercially accepted data access middleware.

2.Use GUI standards for new applications. Pick the tools that suit you best (as long as they are open) and use them.

3.Build a strategy to use Object Oriented application development along with open system standards. Users of IBM systems must actively consider Java, and products such as WebSphere.

4.Prepare for the eventuality that you will be able to build applications from components and piece parts.

No one can argue against the effectiveness that RPG has brought to the traditional world of AS/400 applications development. But, survival in the post-RPG world requires an understanding of object-oriented technology and the revelation that Java might just be in your future.

Related Editorial:

Related Information: