LANSA's Open for .NET solution is designed to help make integrating Microsoft applications and IBM data a trouble-free experience.

Ever roll into work and think you're actually in Gabon on the set of Survivor? Everyone has his little tribe, and no one thinks anyone else is contributing enough to justify their existence?

Think of the IBM i tribe as the red tribe, Fang. Think of the Microsoft .NET tribe as the yellow tribe, Kota. They wrestle, they compete, they try to survive on limited resources. If this describes your world, you may long for the good old days when there was but one tribe, the AS/400 tribe. Those days are over, however, so you might as well accept that there are now two tribes in Gabon. Do you want to compete, or do you want to get along?

LANSA has been helping the IBM i tribe integrate with tribes from other lands for a number of years now with Visual LANSA, its integrated rapid application development environment; RAMP from LANSA, its process for modernizing legacy software systems; LANSA Integrator, an extensible integration server used to exchange data in any format or protocol; and LANSA Composer, a business-process integration tool with graphical mapping. Now, there is LANSA Open for .NET, a middleware data services solution that allows the IBM tribe to live in harmony with the .NET tribe.

Building on years of experience with LANSA Open, a Component Object Model (COM) middleware solution that LANSA has used for years in its client/server technology, LANSA Open for .NET takes a big step further and tightly integrates with the latest versions of Microsoft Visual Studio and the .NET framework. The result is that .NET programmers can easily communicate with DB2 on the IBM i through a class library without the performance limitations and security concerns imposed by a typical ODBC/JDBC driver.

"What this middleware is going to allow the .NET folks to do is simply plug in a class library that provides them with high security, faster performance, and cleaner and more reliable data as they start to move information from their .NET applications into DB2 on the IBM i," says Dave Brault, LANSA product marketing manager.

For many years, all that was required was for users to be able to read the data in DB2 on the System i, and for that, ODBC was an adequate solution. Today, users as often as not need to transact with data on the IBM i from a .NET application. Now the problem of data, as well as application inconsistency, rears its ugly head.

"We realize there is high availability software out there that can make data synchronization instantaneous," says Brault. "But even if you are syncing data real time, there is a potential for application inconsistency where your applications are putting bad data into one database that would not have been validated in another. And now you're trying to sync those, so you can get inconsistencies there as well."

Apart from the programming challenge to .NET programmers of integrating their application with DB2 is that an ODBC/JDBC driver isn't going to deliver the speed of native record-level access. When you are dealing with thousands--or hundreds of thousands--of records, ODBC may prove to be a bottleneck. Brault cites the example of one client that manufacturers all-terrain vehicles (ATVs) that wanted to move older records off the IBM i--where they were cluttering up the machine--yet still have access to them. Questions arose about whether using an ODBC driver to access the very large database would impact the company's production line at some point, and the firm welcomed the speed that LANSA Open for .NET offered when it came to accessing the data from the .NET application it had developed.

The key to LANSA Open for .NET is the LANSA Repository, a metadata layer that stores and enforces business rules from a central location. The Repository, which has been a feature of LANSA technology for more than a decade, is at the heart of the middleware solution and enforces data accuracy through providing a data services layer to govern all database access. All business rules, algorithms, calculations, and relevant APIs reside in the Repository rather than being distributed among a variety of applications. Having such a data services layer as an element of a system architecture can make it a lot easier--and more secure--to open up enterprise data and applications to internal and external .NET applications. It helps eliminate a lot of the database synchronization problems that can arise and helps present what some like to call a "single version of the truth."

The resulting speed of LANSA Open for .NET over that when connecting with ODBC/JDBC is due to the LANSA Repository's ability to implement native record-level access on the IBM i and to compress data before transmitting it. Eliminating the overhead of ODBC is a welcome feature of the Repository, according to LANSA, one that customers greatly appreciate in many fast-paced production environments.

Security is always a concern when opening up data on the IBM i, and LANSA's solution, unlike using ODBC, encrypts the data before it transmits it between the IBM platform and a .NET application over the network. Available security protocols include Data Encryption Standard (DES) and Twofish.

While .NET programmers can reuse enterprise business logic, validation rules, and calculations within their .NET applications by using the LANSA Repository, the feature is not limited to only them. RPG and COBOL programmers can take advantage of having a central repository for these items to serve all their enterprise applications. The concern over having matching business rules between different applications and data sources is so great, notes Brault, that some shops actually will go as far as to collect all the data in their external applications, print it out, and then re-key it into the 5250 interface. And we wonder why people think the IBM i is old technology! It's likely as not because they associate it with these kinds of primitive, and totally unnecessary, sorts of operations. Sharing enterprisewide business rules and resources across all environments greatly improves the speed and quality of application development and makes for better relations between the tribes. Whenever an application is modified or updated, the business rules remain in the repository. If a change in business rules is required, the change is made only once in order to apply to all applications. The business rules are centralized--and they are portable. Any .NET applications you create can access different servers and databases without changing the code.

While the IBM i has an infrastructure to provide for publishing Web services, using LANSA Open for .NET offers a slightly different approach that some may find easier and less costly. Microsoft provides tools for publishing Web services that, when combined with the LANSA data services layer, can be used to access data and services on the IBM i and then offer them up as Web services. The Microsoft-supported Web service can collect the data and pass it to LANSA Open for .NET, which in turn can run, say, an order entry program on the IBM i that inserts the data. The approach can adroitly extend line-of-business systems while protecting servers and databases that manage them.

LANSA is so convinced of the superiority in its approach of having a common repository for business rules that it plans to roll out LANSA Open products for a number of different environments. As part of this initiative, it plans to continue to invest in the product by making it even more attractive to users with easy-to-use wizards and other user-friendly features. The result may be a co-existence of the tribes with nobody being voted off the show and the red and yellow teams living forever harmoniously together in Gabon.