Overcoming the Challenges of Mixed RPG and .NET Development PDF Print E-mail
Programming - General
Written by David Brault   
Monday, 22 February 2010 00:00

Support MC Press - Visit Our Sponsors


Forums Sponsor






Search Sponsor






Can Windows and IBM i live in application development harmony?


Editor's note: This article is an extract from the white paper titled "Using Microsoft .NET to Build Scalable Enterprise IBM i Applications" available free at the MC Press White Paper Center.


Over the last decade, we've watched Microsoft technology shift from running on the fringe of our IBM i enterprise to being intertwined, creating a ripple effect across what we need to integrate with, synchronize with, and monitor on a daily business. As the number of companies running both IBM i and Microsoft hardware continues to grow, so does the number of IT shops struggling to integrate these disparate platforms. In a world of synchronized data, data conflicts and unprotected access to DB2 from Windows applications can make us feel like we are losing control.


This situation prompted Mike Otey to write a white paper titled "Using Microsoft .NET to Build Scalable Enterprise IBM i Applications." It addresses how to maximize the integration of Microsoft and IBM i to provide you with the choice and flexibility you need to achieve the best of both worlds. The white paper's guidelines can help to ensure that your IBM i .NET applications meet the scalability, adaptability, and security requirements of your enterprise. The report is divided into three parts:


  • Part 1 discusses the business benefits that .NET can bring to your organization.
  • Part 2 focuses on the requirements for developing and running .NET applications connected to the IBM i.
  • Part 3 concentrates on the most critical enterprise-level development issues faced by IBM i .NET applications. It also covers some of the most important issues that you need to address when designing production applications that must scale to support hundreds of users across multiple locations and devices.


The remainder of this article contains snippets from Mike Otey's white paper, which can be downloaded here.

Benefits of .NET for the IBM i

Microsoft .NET provides a way to modernize IBM i applications by creating graphical Windows and Web-based applications that integrate with data on the IBM i. In addition, .NET applications can be used as a tool to connect third-party applications, Microsoft server platforms, and Microsoft Office to the data stored on IBM i. While .NET isn't the mainstream development option for the IBM i, it is growing in popularity, particularly for Web applications. Some of the advantages for using .NET as an IBM i development platform include the following:


.NET vs. Java


.NET is not the only graphical development option for IBM i applications. When your organization is evaluating modernization technology, the choice often comes down to .NET vs. Java. IBM has traditionally favored Java over .NET. Even though Java and .NET have a number of similarities, they also possess some major differences. Both Java and .NET are object-oriented languages. Java and the .NET C# language in particular were both essentially derived from C/C++. Both have hierarchical namespaces or class libraries and provide automatic garbage collection. In addition, both platforms require a host runtime component in order to run applications.


Real-World Production Application Issues


Getting the initial building blocks in place and connecting your .NET applications to the IBM i are certainly essential elements in the process of building IBM i .NET applications. However, the initial connection and database access is just the starting point. Enterprise-level application development requires attention to real-world application development issues, like scalability, data integrity, integration, team development, and security. In this section of the white paper, you'll get some hard-to-find architectural guidance and recommended best practices for building enterprise-level IBM i .NET applications.


Data Integrity


Another vital issue for enterprise applications is the accuracy and integrity of corporate data. Whether it's used to generate management reports or to populate a data warehouse for business analytics, enterprise data is the basis for management's decision-making process. Inaccurate data can render these reports ineffective, or, even worse, it can lead to bad managerial decisions. Guarding against data corruption from .NET applications is much more important than it is for native IBM i applications because the legacy 5250 programs already contain all the enterprise business logic and validation rules. If your IBM i .NET applications generate bad data and corrupt DB2 data on the IBM i, the application won't be trusted by either end users or management. This can lead to the application being abandoned or replaced. In some cases, it can also result in the termination of the personnel involved if there are adverse effects on the organization's ability to do business.




Security is another essential design consideration when developing IBM i .NET applications. Most IBM i applications utilize menu-level security where code in the application governs the access rights for different types of users within the same application. It's important to realize that .NET data access mechanisms like ADO.NET and the .NET Data Provider will not be governed by the same menu-level restrictions that controlled end user security within your 5250-based applications. However, don't infer that .NET access to the IBM i is insecure; .NET access is controlled by native IBM i object-level security instead of menu-level security. This fundamental difference underscores the importance of planning and implementing your IBM i object-level security.


Siloed Development Teams


Another enterprise application development issue facing IBM i organizations today is managing siloed development teams. Many organizations with an IBM i have two sets of developers: one team dedicated to IBM i and another for Windows. The personnel comprising each respective team are typically very knowledgeable about the platform they work on every day. However, by the same token, they typically have very little knowledge about the other platform. This disparity becomes problematic when organizations embark on developing IBM i .NET applications. Typically, the .NET development team is tasked with developing all the Windows applications, which makes sense to management because that group has the best expertise in developing on that platform. However, problems will arise because the vast majority of .NET developers don't understand the IBM i. The IBM i is a sophisticated and unique computing platform that has many features and attributes that are not known to Windows developers.


Complete Platform Integration


Today, most IBM i .NET applications use a SQL-based .NET Data Provider to integrate with the IBM i database. The IBM .NET Data Provider provides your.NET applications with seamless IBM i database integration for reading, inserting, updating, and deleting data from the IBM i's relational database. Remember, database access is only one aspect of platform integration. Real-world production IBM i applications almost always require native platform access to features like CL commands and programs, RPG programs, i5/OS APIs, data queues, data areas, the IFS, spool files, job queues, and output queues.


Find out more by downloading the free white paper titled "Using Microsoft .NET to Build Scalable Enterprise IBM i Applications" from the MC Press White Paper Center.


David Brault
About the Author:
As Product Manager at LANSA, David Brault draws on his knowledge of IBM i (System i, iSeries, AS/400) technology to help determine the market message for LANSA's products. David has over 15 years of experience in the IBM i industry, including extensive involvement integrating IBM i applications with various Windows, Web, and wireless technologies. He is currently responsible for launching new LANSA products and serving as the U.S. product line expert for press and analyst briefings. David is a member of the COMMON Americas Advisory Council (CAAC) and a frequent speaker at COMMON and other industry events.


Last Updated on Monday, 22 February 2010 00:00
User Rating: / 0