This movie requires Flash version 8 or higher.

It Appears that you do not have the Flash Plug-in Installed or you have an older version of the plugin. Please update or install the Flash Plug-in to view this content.

Visual Application Framework

Developing visual applications that meet the needs of today’s discerning user is a real challenge. Knowledge workers expect applications to look and behave like Microsoft Office and visitors to your Web site are only one-click away from your competitor.

Programmers with classic skills – like writing procedural RPG code or arranging a 5250 terminal screen – can struggle with key GUI design concepts and often miss the mark with their first Windows or Web application. Even programmers with modern day skills – like the Visual Studio.NET toolset and developing in C# or VB.NET – can fail to accurately capture user requirements. To ensure a 'right first time' result, LANSA provides a Visual Framework that has been used by developers of many different kinds of applications and already accepted by millions of users.

Why Use a Framework?

The framework architecture provides a proven development standard for creating robust .NET, classic Windows or rich Web applications.

LANSA’s Visual Framework makes developers as productive as possible by providing templates for common commercial applications. The framework assists in the prototyping, design, deployment and maintenance stages of the application development lifecycle.

The Benefits of Prototyping

Developers can be uncertain of what a commercial-grade application should look like and how they should structure the underlying code. And users are notoriously bad at defining what they want, but they know what they like when they see it! Frameworks remove the guesswork by applying proven standards. Prototypes can be defined in minutes and if the application is browser-based, designers can email a link to the prototype that users can play with and provide immediate feedback.

The prototype is not thrown away but gradually converted to a real application by using a snap-in architecture. You complete your application by replacing the prototype parts with real programs that reflect your actual business logic.

Code Assistants generate much of the code required and an expanding library of reusable Fast Parts allows developers to rapidly assemble powerful and rich user interfaces.

Flexible Deployment Options

Your framework-based application can be deployed as a Windows executable on the desktop for expert users, or as a Web application using advanced DHTML with Windows-like functionality and zero-client deployment. Or, for the best of both worlds, choose to generate a .NET rich-client with ClickOnce deployment to achieve optimal Web performance with functionality on par with a classic Windows client. No other framework provides such parity between a Windows, Web or .NET user interface from the same code base.

Boost Developer and User Productivity

The framework was designed to boost developer productivity by providing an easy-to-use and intuitive application framework. It hides and abstracts some low-level functionality to achieve higher levels of productivity and a shorter learning curve. Maintenance is easier as applications follow a consistent design, making it easier to understand code.

The framework enforces a graphical user interface design that follows the standard Microsoft conventions that almost all users are familiar with, whether at work or at home. This model provides a cockpit or dashboard-style design where everything that a user might need to do is just a few clicks away.

Business Mashups

The framework is also a perfect environment for mashing-up business applications. Business mashups are 'composite business applications' that combine disparate data elements and applications into a new streamlined user experience.

 
 
 

The elements of a business mashup that can be snapped into the LANSA Visual Framework can include:

• Parts of your current applications – as-is 5250 green-screen format
• Parts of your current applications refaced and repurposed
• New components developed in C#, VB.NET or LANSA
• New components developed in RPG, then refaced
• Applications presenting data from external sources via Web services or third-party APIs

Business mashups are particularly useful as a new technique for modernizing legacy applications. The useful parts of a green-screen (5250) application can be isolated, wrapped and then snapped inside the framework. This means that all navigation is handled behind the scenes and the user enjoys a simple point-and-click interface. The real beauty of this approach is that old and new application functionality can sit right alongside each other in the same user interface – no more ALT-TAB acrobatics between multiple windows. New logic can be added to the mashup so that manual, repetitive tasks are automated and errors are handled before they ever reach the back-end systems.
 

Meta Data Repository

Business rules govern the behavior of your systems and the integrity of your data. But where are these rules stored, when are they enforced, how are they documented and who is authorized to apply changes? These policy decisions make the difference between having an agile enterprise architecture or a rigid accidental architecture.

In conventional software design these rules are hard-coded inside programs and also applied at the database level using triggers and stored procedures. It is common to find the same rule repeated in multiple programs, making it hard to gauge the impact of any changes. This uncertainty, or fear of change, is hindering the creation of agile enterprise architectures and will eventually turn legacy systems from corporate assets into liabilities.

"The legacy code is a monster. I don't have the time and money to rewrite code from the early 1990's. Right now the game is to cut costs and LANSA gives me the tool that I can use to do this."
Nick D'Alesandro, STRATTEC

One can see that codifying the business rules at the program level means that it is impractical to share the same set of rules across incompatible systems. The net effect is that time and money are spent applying old rules to new applications rather than enabling those systems to reuse the existing logic. The challenge of sharing rules between systems is a major impediment to properly fusing the infrastructure. A full understanding of these rules and policies is also crucial when planning to migrate workload from one platform to another.

 

 

iFusion.net employs a repository-based architecture to ensure that rules governing transactions are centrally maintained and enforced by all programs regardless of the platform or development language (C#, VB.NET, RPG, COBOL, LANSA, Synon, SQL, PHP). The result is zero duplication of business rules, tighter security, faster performance and more assured data integrity for organizations that depend on DB2 and SQL databases. This pragmatic approach is especially attractive to IT departments that run IBM i servers and have limited resources with which to modernize their core systems.

Once you have a fully populated repository you are no longer tied to a particular combination of hardware, operating system, database or user interface technology. Contrast this flexibility with, say, Microsoft .NET applications that only run on Windows servers or large J2EE applications that demand powerful IBM servers. Our customers describe the Meta Data Repository as their insurance against technology change, because it insulates them from the risks associated with being locked into a specific configuration.
 

Data Services Layer

A fundamental tenet of the iFusion.net architecture is to keep programs separated from the databases upon which they depend.

In every system there exists a set of rules that control how programs are allowed to create, read, update or delete data. These rules exist to maintain the quality and consistency of the data and also to protect integrity in a multi-user, transactional environment. Failure to follow the rules can lead to anything from bad data values in a report to a total system crash.

Normally these rules are maintained at the database level – using stored procedures, field validation, triggers etc. – or in the application programs. One can see the obvious benefit of enforcing rules at the database level, being that this centralized model eliminates duplication. The downside being that every database vendor has their own proprietary way to implement concepts like triggers and stored procedures so that enforcing rules at this level locks you into a specific vendor. You can avoid this kind of database lock-in by coding rules at the application layer, but then every program needs to incorporate the same set of rules which is not only a development burden but causes a real maintenance headache.

 

 

The iFusion.net platform contains a data services layer that provides a single access point for all data and serves to abstract formats, locations and conventions. Specific programs – called Object Access Modules – are generated from a data dictionary held in the repository. These OAMs know about the structure of the database (fields and files) and contain the rules that govern all create, read, update and delete transactions. So, for instance, whenever any program anywhere on the network wants to 'create_New_Employee' in the 'comp_Employee' table in the HR system that request will be directed via the appropriate OAM. Future changes would only cause that specific OAM to be regenerated on the server and would not impact any other programs. It is possible to make an OAM even more intelligent by using built-in features like database independent triggers or derived fields that perform calculations or concatenate strings on-the-fly.

These OAMs can be used by any program running on the IBM i server regardless of the development language used e.g. RPG, COBOL, LANSA, Synon, PHP etc. The iFusion.net technology also includes middleware that enables applications built with the .NET framework to access these OAMs. The net result is that all of your applications – irrespective of their age or technology – can use a common data services layer to access the underlying databases.