Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS

Transcription

1 Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS In order to ease the burden of application lifecycle management, tooling for rapid application development (RAD), maintenance and deployment is being built more and more into Integrated Development Environments (IDE s) these days. However, developing and maintaining large commercial applications where database and code synchronization is imperative is not often a trivial task even with this tooling. Agile Business Suite (AB Suite) from Unisys is a new object oriented Fourth Generation Language (4GL) environment that integrates development, testing, versioning and application deployment functions within Visual Studio.NET. Code generation, automated database migration and integration with a diverse set of application integration technologies forms the basis for a powerful team centred RAD tool for building and maintaining large, complex back-office enterprise applications. AB Suite components AB Suite has three main components: the Modeler, the Builder and the Runtime as depicted in diagram 1. The Modeler is implemented as a project plug-in for Visual Studio.NET, so the development and debugging environment looks and feels quite natural for.net developers. The Builder is also integrated within Visual Studio.NET and allows application models to be code generated locally, and compiled and deployed on local and/or remote Runtime environments. The Runtime component provides library support for deployed database centric applications that use MS SQL Server or Oracle databases. AB Suite is capable of generating and deploying applications to a variety of operating environments, but in this article we will concentrate on the Microsoft Windows platform and.net based technologies. Diagram 1. AB Suite components for.net

2 Application development Unlike most other application development tools, the Modeler uses a Microsoft SQL Server database to hold application model and source information instead of sets of text files. Although using a database to control access to shared resources is very useful for small teams of developers, once a team reaches a critical mass of more than just a few developers or code interdependencies become more complex, a source code control system to manage shared resources becomes a necessity. AB Suite supports the standard SCC API for integration with version control tools such as Microsoft Visual Source Safe, so having multiple teams of developers working on large backoffice application projects is straightforward. In order to manage change across teams of developers building and maintaining enterprise applications, project teams are often required to adhere to strict development standards. This often means adopting a set of coding standards, using common trusted code patterns and attempting to reuse as much proven code as possible. Similarly, reducing complexity usually mitigates project risk. In order to help development teams achieve these goals for application development, Unisys has introduced a AB Suite framework and data model. Framework and data model Working with AB Suite projects is relatively straightforward for developers with experience of Microsoft Visual Studio.NET and even more so for those with an understanding of object oriented programming techniques. An AB Suite project is a model that contains one or more Segments, each of which is a logical representation of an application. As a model, it is much easier to change than a system developed in a traditional 3 rd generation programming language. Changing a logical element of the model will cause the Modeler to make the appropriate updates to other application entities such as classes, interfaces and database tables. Dictionaries are provided to allow developers to easily manage common data types for systems. For example, a data type called Balance might represent a number of up to 8 digits, with 2 decimal places. Each time you need to work with a Balance in your model, you can reference this dictionary definition. In addition to specifying the properties of a data type, you can also specify value-checking criteria. For example, the condition this > 0 ensures that only values greater than zero are valid. Changes you make to a data type will flow through to any elements that derive from it, including database attributes. Global dictionaries can be used to share dictionary definitions across multiple applications and Local dictionaries can be used to define data types for use in a particular Segment. In the Modeler, the class is the basic building block of an application. In addition to standard classes, a set of stereotyped classes exhibiting more powerful behaviour have also been provided to draw on the capabilities of the AB Suite Runtime component. By systematizing much of the core infrastructure required for database centric Online Transaction Processing (OLTP) applications, you can concentrate on coding the logical business rules for applications and not have to worry about coding the plumbing. Understanding the behaviour associated with each of the stereotyped classes will allow you to create much of your system without having to write a lot of code. A functional prototype of the system including a user interface can therefore be developed very quickly.

3 Each class may contain Attributes and Methods. Attributes are variables that are members of a class. Attributes can be defined as having persistence and/or presentation. Attributes having persistence have a database representation. The database schema is defined at generate time by grouping the persistent Attributes into a set of tables. Attributes that have a presentation form part of external interfaces. These Attributes can be painted in a graphical form editor (using Visual Studio) and eventually these forms can be code generated into one or more Graphical User Interfaces (GUI) such as WinForms. Methods are code fragments that are part of a class and are invoked by the framework or by user developed code. You write code in a script called LDL+ (see diagram 2) which has the full power of object oriented constructs including encapsulation, composition, inheritance and polymorphism. Diagram 2. Writing code in LDL+ Stereotyped classes The main stereotyped classes provided for building applications are called Segments, Folders, Ispecs (Interface Specifications) and Reports. As was mentioned previously, the Segment is a logical representation or model of the enterprise application. A Folder is a useful construct for grouping classes together in whichever way you might think useful. For example, you might like to subdivide the application into a set of functional areas. Ispec and Report classes are contained in Segments and Folders.

4 Ispecs are classes that define database persistence and/or external interfaces. An Ispec with persistent members will have an underlying database table in which to store these attributes. An Ispec that has attributes with presentation properties will define an external interface which could include a GUI representation. Ispecs having attributes with persistent and presentation properties will have both a database table and an external interface. All generated Ispecs form part of the OLTP components of the application and Ispecs with attributes having presentation properties represent an executable user transaction type. In order to make developing in AB Suite simple, the Runtime component provides support for a framework that governs an Ispec transaction instance lifecycle. Importantly for developers, usage of this framework guarantees that transactional data integrity is automatically maintained without having to explicitly code transaction demarcation boundaries and worry about other concurrently running processes. In order for the Runtime component to make such a guarantee, Ispecs have three predefined methods which are invoked by the framework at strategic points in the transactions lifecycle (see diagram 3). Diagram 3. Transaction lifecycle These methods are called Construct, Prepare, and Main. You simply fill in these methods with appropriate application logic and the framework will automatically invoke the code at the correct point in the transactions execution. The Construct method is called by the framework to initialize an object instance. The Prepare

5 method is called after user input has been received and input data validation completed, providing a point at which to complete more complex data validation checks for the transaction. Finally, the framework conditionally calls the Main method which usually contains the bulk of the transactional work. You are not limited to using just these predefined methods, you can write as many of your own methods as you desire. Unlike Ispec transactions, a generated Report is a self-standing executable process which is not part of the on-line system, although it does share the same database. It is a batch process which can be used to update and/or query the database. Reports can have many explicitly defined database transactions which allow greater flexibility for bulk query and update operations. Unlike Ispec transactions which have a defined execution cycle, a Report simply starts execution in its Main method. The Runtime component provides services such as automatic restart and recovery for Reports. You don t have to code any of this yourself, the AB Suite infrastructure provides the plumbing which means you can concentrate on coding the business rules. Automatic recovery of failed long running processes mean that a restarted Report can start database and file processing from the point at which it failed, not from the very beginning. Building and deploying your application Once the enterprise application has been developed or is under maintenance, it will need to be deployed to a server platform. AB Suite keeps deployment information with the logical model definition in the development repository. Deployment information is maintained by using the Visual Studio.NET environment. You can define multiple sets of deployment configuration properties, one of which can be selected at the point you decide to build and deploy an application. AB Suite provides a one-click deployment mechanism, the first phase of which is conducted by the Builder component. The Builder translates the models design information into a running database application and clients to access that application. During this process, the Builder combines configuration information with structural information and logic defined in model. The code generation uses a set of file templates which provide a standard code structure for each stereotyped class. Triggers contained in the templates cause the Builder to generate and insert specific code fragments which correspond to user defined logic and declarative properties of classes. Building large, complex applications often requires that generation and deployment times be minimized. To this end, AB Suite provides a change analysis mechanism that compares the current state of the model to the files comprising the previous version of the application to determine which elements need to be generated. The Builder stores the latest previously generated files for each configuration, so it only needs to regenerate distinct parts of the model that have changed. AB Suite generates (managed) C# code for each Ispec and Report. The Runtime component framework provides the basis for a Service Oriented Architecture (SOA) into which the Ispec services are plugged. Using the optional Component Enabler product, interfaces to a variety of different.net presentation and integration

6 technologies (see diagram 4) can also be automatically generated. For example, in this way it is possible to code generate and deploy ASP.NET, Web Services and MSMQ interfaces for designated parts of the application without having to code anything extra. Since the interfaces are code generated automatically from the model, there is no further maintenance to do when the model changes. Diagram 4. Component Enabler The generated C# project files are compiled and linked using the Runtime component libraries and input to the deployment project. The deployment project is built to create an MSI deployment package. AB Suite Solutions may contain a number of projects, not all of which need to be AB Suite projects. For example, AB Suite is capable of deploying a Solution containing a C# project and an AB Suite project across multiple platforms. You should also note that access to AB Suite objects from other.net language environments (and vice versa) is supported, which means that you can choose to use the right tool for the right job. Synchronized deployment of code and database modifications One of the hardest parts of building large, complex transactional applications is maintaining and extending the application, especially when modifications to the database schemas are warranted. Maintaining synchronization between the data structures used by the transactional programs and the database schema can present problems which are usually only identified at runtime. Although tools exist in IDE s to discover program dependencies, managing change in large database applications is often an error prone manual task. Having identified how

7 the database schema needs to change, deployment usually requires manual schema changes and some form of manual data migration. In large production deployments these are often error prone critical procedures. This is where this 4GL technology excels. You don t really need to worry about the dependencies between the code and the database, and operations staff do not need to worry about database schema modifications and data migration. AB Suite handles all of this automatically by keeping track of where every Attribute and Method is used or changed between successive deployments of the application. It therefore knows what application components need to be regenerated, recompiled and redeployed. By comparing the currently deployed database schema with the new schema to be deployed, columns and tables can be altered, added and removed. AB Suite also manages the migration of the data automatically, unloading and reloading tables if so required. Impact analysis tooling is also provided so that you are able to understand what deployment time activities will be done prior to actually running a deployment. Conclusion Developing, maintaining and deploying large, complex back-office enterprise applications is not an easy task. AB Suite offers a state-of-the-art object oriented 4GL environment that simplifies this task. Allowing project teams to focus on writing the application business rules instead of worrying about the infrastructure plumbing reduces the problem scope and mitigates project risk. The AB Suite application lifecycle management tooling coupled with code generation facilities providing integration with.net runtime technologies such as ASP.NET, Web Services and MSMQ make building and maintaining SOA based applications targeting.net a snap. Michael P. Leznar is managing director and principal consultant at Leznar Consulting ( During his 25 year long career he has been active with all facets of computer software engineering (development, support and management) including product management, project management and technical consulting. Mike has worked in many different worldwide locations in both management and technical roles. Mike has a Bachelor of Applied Science (Computing) degree (Honours) from the University of Technology, Sydney, Australia. His address is mike@leznarconsulting.com.