Sample Application Architecture Document (Insurance Business)

Overview

The XXX project uses the following building blocks for construction of the application:

1. Powerbuilder - PB is used to construct the presentation portion of the application which is resident on the client.

2. Sybase - the application data is stored on SUN database servers and Sybase is the relational database management system used to control and access the data.

3. C/C++ - C programs are required to interface PowerBuilder and Cobol and these interfaces will be developed using C.

4. Base objects - a number of objects are available for use to simplify the creation of the application.

5. SQL stored procedures - the PowerBuilder scripts will not contain embedded SQL statements. The required statements will be stored in Sybase's stored procedure table resident on the Sun server. The PB script will execute the stored procedure. This approach reduces network traffic and provides database security since users must be granted execute access to the stored procedure.

6. Messaging - remote procedure calls will be used to send/receive messages between logical applications. Messaging utilizing Sybase's Open Client / Open Server products will be used to access AutoFund data in VSAM files.

Logical Boundaries

The business application will consist of the following major business areas:

1. Underwriting (auto, commercial, personal)

2. Claims

3. Finance

4. Reporting and decision support

One of the major design goals of a client/server application is to develop a model with the characteristics of granularity and loose coupling. Granularity means that a module performs a single function and loose coupling suggests that the module does not have detailed knowledge of database structures. For example, in a loosely coupled system, the claims area would not need to know the specifics of the data in the underwriting area.

To accomplish loose coupling, logical areas must communicate with each other via messages. Messages will contain sufficient information for the target application to perform its functions without needing to look at the source application data.

The XXX application will use stored procedures to implement two tier message passing. Although this does not provide the maximum flexibility in terns of coupling it does provide an acceptable solution.

EXIT Language

PB will not be used for all programming requirements. Modules running on the Unix servers, for example, can not be written in PB. As well, other common routines which may run on the client station might be written in C/C++.

Sybase provides two products, OpenClient and OpenServer to facilitate remote procedure calls. This mechanism will be used when a PB script must call a module resident on the UNIX server.

Client Workstations

PowerBuilder Graphical User Interface

The PowerBuilder GUI is based on standards outlined in the Systems Development Environment Design Guide and is based on the custom SDE. The interfaces are based on MDI frames and many major windows are based on tab folders (one window with multiple "tabs" for access to larger quantities of data). Windows and objects on windows are inherited from the SDE to provide consistency and ease of maintenance. The applications also provide hooks for client maintained help and interfaces to client maintained Word and Excel documents.

PowerBuilder Custom Systems Development Environment (SDE)

The PowerBuilder SDE consists of a design guide, custom objects to be placed on windows, base windows to be inherited by applications, non-visual objects to provide services for typical screen processes, common windows to be hooked into multiple applications and transaction management services.

The design guide provides developers with guidelines and standards for windows development. It also includes instructions on how applications are to be built, how to use screen services, how to use the transaction management and how to hook in common windows.

Custom objects are used to ensure the application is consistent and that basic code need only to be written and maintained once. Examples of custom objects in XXX include datawindows, command buttons, static text as well as complex objects such as a notepad editor.

Base windows are used to eliminate developers from having to write basic coding such as checking for updates when closing windows as well as providing places to put custom scripts for SDE triggered events. Base windows exist for all window types.

Non-visual service objects are created to allow objects to act differently depending upon the use on a particular window. For example, a datawindow can have a different NVO to allow it to work like a free form, single select, multiple select, file manager select, etc.

XXX uses a number of common windows for common functions. Examples of these are notepad entry windows and name/address update windows.

Transaction management in the SDE evolved from a number of techniques into a method of dynamically generating stored procedure calls. Developers will create datawindows to view and update database tables. During prototyping and development, these datawindows can directly update tables (to increase productivity). Once a datawindow is close to being completed, the select, update, insert and delete stored procedures are created. The datawindow can then be converted to use the stored procedures. A utility application is used to convert selects into stored procedure calls (and generate all four types of stored procedures). The table name in the datawindow update parameters screen is then prefixed with a special string and the datawindow is now ready for stored procedure use.

Non Visual Objects

Non visual objects are used to encapsulate the business logic and isolate it from the interface layer of the application. This will enable future applications to use the business logic on different interfaces. NVOs also provide a means of having distributed objects that can be stored on a file server or the SUN server to ease in maintenance, performance and software distribution.

SUN Servers

The XXX is architected to a four server model: Claims, Finance, Underwriting and Information Warehouse. Claims, Underwriting and Finance (which run the online systems) communicate to each other via the use of Remote Procedure Calls (RPCs). The Finance server is the holder of common tables (code tables and name address tables). All inserts and updates to these tables are done to the finance server even if the source of data is Claims or Underwriting. The updates are then replicated back to the claims and underwriting servers for use in Select statements.

All data is replicated to the information warehouse server where most reports are run. The information warehouse also creates summary data which is loaded on a periodic basis.

Each server contains the components described below.

PowerBuilder for Unix

Powerbuilder for Unix is used to write complex business applications that are not screen dependent (i.e. batch jobs). It also contains a "Report Runner" application that is used to run reports and schedule periodic jobs. Applications here use the same SDE as do the Windows based workstation.

Sybase Stored Procedures

Stored procedures are used to access all database tables. Each server contains multiple databases, one of which is a procedures database. This database contains views for all the other databases and all procedures are written against these views. This isolates the programmer from having to know which database contains which tables.

Security is granted against the stored procedures and not against the tables directly. This allows users to create custom profiles based on the applications procedures.

Stored procedures are also used to write high volume and performance critical processes (such as processing general ledger transactions or renewing policies).

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.