A short history: LANSA was released in 1987 as a development tool for creating native 5250 (green-screen) applications for the AS/400. Even though the product made AS/400 development simpler and more productive, applications that were developed with this version only interacted with a single database (DB2), displayed a single interface (5250), and ran on a single operating system (OS/400).
Since that initial release, the product suite has evolved into LANSA 2005, which now enables developers to deploy to multiple databases, interfaces, and platforms.
Database layer: LANSA 2005 interacts with many databases, including SQL Server, Sybase, and Oracle. Switching the application database, for example from Sybase to SQL Server, requires no code change to the LANSA applications because LANSA automatically generates this layer and shields it from the developer.
Application layer: LANSA runs on a long list of operating systems, including OS/400, i5/OS, Windows, UNIX, and Linux (check the Web site for a complete list).
Interface layer: LANSA calls its support for the interface layer "one-click device support," which simply allows the developer to switch or add clients easily and quickly. You simply create a Web Application Module (WAM), and, because WAMs use XML/XSL under the covers and support MVC design, the data can be displayed in the markup of your choice: XHTML, XML, etc. In the end, it means users can see the same data on their PDAs as in their Web browsers--with new device support added in the blink of an eye. At the other end, it means that the developer has to write only the business logic; the markup is completely auto-generated (hence the one click "blink-of-an-eye" delivery time!).
Figure 1: With the interface layer, you can switch and add clients easily and quickly.
Even more powerful at the interface layer is the ability to expose the WAM application as a Web Service. When David explained it to me, it was surprisingly simple: The WAM consists of one or many Web Routines, which essentially represent a screen with several input/output parameters. The relationship between these screens and their input/output parameters is maintained/executed via a LANSA command called a Web map. For example, a typical inquiry program contains two screens--a search page and a results page. The search page usually requests an input field (for example, an employee number) and then sends that input field's value to the results page. The results page expects to receive the employee number and uses it to gather the results to be displayed to the end user. You get the picture.
Amazingly, the same input/output parameters used to create user interface screens are also used for creating the methods for a Web Service. The impressive part is that the developer doesn't have to repackage or manipulate the WAM in any way to enable the program to become a Web Service, as one might have to do in J2EE. The developer simply right-clicks on the WAM and says, "Expose as a Web Service."
Figure 2: Creating Web Services is as simple as a mouse-click.
The next layer is the LANSA language and its Repository.
Database access layer: The Repository is an interface layer that controls how the data that is delivered interacts with the code that uses this data. In MVC terms, this would be the C (Controller). All LANSA code interacts with files at an object layer; the Repository objects are either files or fields. Thus, similar to "facade" EJB in Java, a field object encapsulates the data and applies logic and rules to it. A file object encapsulates all the field objects, plus additional information like validation and calculation logic, field level help text, multilingual support, etc. These objects, and all the benefits associated with them, are made accessible to every interface supported by LANSA (5250, Web, Rich Client, etc.).
What makes this all possible is the core component: the LANSA programming language. Actually, Rapid Development and Maintenance Language (RDML), LANSA's underlying language, allows the developer to write programs as easily for Windows as for AIX, because the developer just needs to know RDML--and maybe not really so much, since the visual environment generates much of the code through a wizard technology LANSA refers to as "templates." What separates LANSA 2005 from other IDEs? The developer doesn't ever really need to go below the generated code level. All coding, syntax checking, and debugging is done within LANSA 2005.
The process is simple: Create a majority, sometimes all, of your application using a LANSA template; RDML is generated under the hood. Given the developer's choices of native OS language, LANSA will then generate, say, RPG ILE or C/C++ code for iSeries, Windows, UNIX, or Linux. On the front-end, once again based on choices made by the developer in the IDE, client code can be generated for anything from a browser application, to a Web Service, to a wireless pocket PC program. But the developer only concentrates on the application logic.
Figure 3: Using templates, developers can generate code for anything from a browser application, to a Web Service, to a wireless pocket PC program.
Where does that logic go? Well, where should it go? If we are talking truly decoupled, MVC/OO design, the logic shouldn't even go in the application. True to form, LANSA stores this logic in the Repository, where it can be reused and shared by other applications. Let's look at a couple of examples.
Remember that Repository objects can be fields--fields extracted from a database. Often, developers need to manipulate the format of the data before it goes to another application (e.g., date flipping from 6- to 8-digit, substringing, concatenation, etc.). All these common, yet volatile bits of logic go into virtual fields in LANSA--virtual because the actual fields wouldn't/shouldn't appear in the actual database. These virtual fields are stored in the LANSA Repository (objects), not in the application code. Thus, any change to this logic (and there will be change!) requires recompiling only the Repository object, not the applications themselves. Brilliant!
Virtual fields can be taken to the next level when file relationships are defined in the LANSA Repository. LANSA calls these special fields predetermined join fields. Also virtual, these fields are calculated when accessing related files, like join relationships and parent-child relationships. For example, let's say a developer needs to display order history information on a screen where some data comes from the order header file (order date and total), some from the order detail file (minimum, maximum, and average line item amount), and some from the customer file (shipping and billing address). A typical RPG developer would need to access all three files and create the logic for minimum, maximum, and average line item amounts or create a complex SQL statement to do so. But the LANSA developer can gather all the information, including the minimum, maximum, and average calculations, while working with one file--without using SQL. All this can be done using the Repository and predetermined join fields.
Additional features included in the Repository are rules and triggers. Among these are checks: list checks check to see if the value is in a list of values (for example, a gender check would scan against the list of male and female); range checks check to see if the value is in a range, say 10-20; date checks check the date format, but also check constraints--so many days in the past or future; logic checks can be inline RDML statements, or they can call an external program that can be APIs written in RPG, COBOL, Windows, or LANSA. Triggers may sound familiar to those who work with DBAs, but LANSA's triggers are not stored at the database level; they are stored in Repository objects, making them platform- and database-independent.
All in all, what LANSA 2005 offers the 5250 developer is what the industry demands:
- Rapid development, provided by a highly intuitive graphical IDE and a single, intuitive development language
- Rapid multi-client exposure (MVC), provided by LANSA's innovative WAM design
- Quick reaction to rapidly changing business logic, provided by LANSA's robust Repository architecture
- Integration of data and services across platforms (SOA), provided, once again, by LANSA's Repository and internal code generation engine
There's not much more you could ask for in a development tool for 2005! Be sure to sign up for a free Webinar.
LANSA Inc.
3010 Highland Parkway, Suite 950
Downers Grove, IL 60515
Telephone: 630-874-7000
Fax: 630-874-7001
Web: www.lansa.com
Email:
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online