k-press.ru - Software
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

asc - the conception of building scalable financial applications on the component model base

Problem in brief

The present-day business makes more and more hard demands to the software and its quality. You can interpret "quality" not only in terms of reliability, productivity and scalability, but in terms of advanced functionality and expandability (by user or independent service company) too.

It is rather difficult task to create up-to-day application that meets the requirements described above. Such a problem, perhaps, can be solved by a big corporation like Microsoft or Oracle. Small Russian software companies simply have no resources for the development of a powerful software.

You can use 4GL-languages and CASE or RAD tools, or some tools from independent developers to provide reliability, as well as for the reduction of the development time. However such an approach can solve only technical problems. And we must keep in mind that after choosing of some development tool we'll be bounded up by specific technology (for instance, by file-server technology or by two-tier client-server technology). This choice will bind us to the certain technology and sometimes we'd even need to completely rewrite our product to turn to other technology. If you choose a hi-end technology like multi-tier client-server technology you must be assured that a new (better) technology will appear in several years and in any case you will have to rewrite your application.

However these problems are waning in front of fact that an average firm cannot execute a comprehensive and high-quality realization of all the functions that you can meet in the busyness world. So developer must create a universal system that can cover all aspects of average enterprise's life, but in a very generalized manner, or a high-professional and flexible application, designed for the automation of some narrow problen.

I think that the problems of both approaches and clear and do not need any further explanation...

Let's imagine that several vendors developing financial software decided to join their efforts and to create a product that have no imperfections mentioned above. It is possible if that product is based on the component approach. Each vendor creates one (or several) component of the resulting product.

How can you join the components from different vendors? You must remember that they must function as a a single whole and, furthermore, they must be extensible by the third-party components. 

All the components must work with the common core that provide a common model of the data storage and that hide the low-level details (like interaction with DB) from the application programmer. This core must be created using the component technology and it will be a component too. The core components define the core abstract layer.

There are intended three levels of abstraction:

1. End-user application level. An end user has an interaction with it. This level can be called a component configuration level, because it is based on the components of application. This components can provide the interfaces to another components of the same level. They can have their user interface. The components of this level can use the program interfaces of another components and of the core. The application components can be created by the dynamic core interface generation tools or by a professional development tool. There are several requirements. The first requirement: the component must be designed as a non-visual COM object, implementing the server-side business logic, or as an ActiveX control for the development of the user interface . The second requirement: such a component must perform any modifications of common data only through the core application interface. There are another requirements, but it is too early to speak about them. Components can be configured through the core-level tool.

2. Core level. This level combines the object model of the core with the design tools that helps to extend the functionality of the end-user application. This level provides the dynamic loading of components and their interaction. This level can be considered as a design environment that helps to create a complete application on the fly. Main features of the designer are:

   • dynamically customizable interface (by the final user also);

   • The Automation support based on a technology like MS VBA (forms, script language etc.)

   • Three-tier architecture that allows components to separate business logic from presentation logic (that works on the client) and busyness logic (that works on the remote server(s)).

Core level is responsible for the data logic handling. This logic can be managed with the help of static (rules) or dynamic (triggers) verification, and the data processing is performed not on the DB-level but on the object model level (we'll tell about it later). Dynamic customizing feature allows advanced user, application programmer or application component to customize the object model. Analytical designer creates, describes and customizes objects in the visual environment (or programmatically), and designer creates needed infrastructure (DB tables, metadata and handlers) automatically. Abstracting from specific technologies allows to turn to new technologies and DB by changing only core level and/or lower levels. Today low-level components are supported by such famous DBMS like Oracle, DB2, MS SQL Server, Informix and MS Access. The support of such different data sources does not affect (at least does not affect significantly) on the performance because of using multi-tier architecture. This support allows to create universal well-scalable systems. In the future, when the RDBMS standard will be created it will be possible to use their advantages without changing of an application code.

• 2.1. The core level is based on core components. These components are the "details" that are forming the core. They can be used separately from any development tool that supports the ActiveX technology (MS Visual Basic, MS Visual C++, Borland Delphi, Java etc.). An example is a component that allows an advanced handling of directories. The functioning of each core part is provided by the specific core component. Each independent developer can create the core components thereby extending the functionality of the core. The creation of the core components has the same restrictions as  for any other component. But in first case you don't need to use only core components while accessing the data. It is strongly recommended to access the data using low-level asc-components in such case. Otherwise the programmer will be responsible for portability and scalability of designed core component. It is very difficult to describe here all these features. If you are interested in this, you can find the prototype of such a component in Components - Invoice. This prototype was created using obsolete technologies (two-tier client-server technology based on MS SQL Servеr) however it can give you a general notion about the described item.

• 2.2. Designer. Allows to create and customize and performs component configuring. You can customize the data structure and busyness logic using the designer.

• 2.2. Конструктор. Позволяет создавать, настраивать и выполнять компонентные конфигурации. С помощью конструктора происходит настройка структуры данных и бизнес логики.

3. Low-layer component level provides the functionality of two previous levels. It is assured by  ActiveX container that provides the dynamic form loading, their customizing and saving. It is created as an ActiveX control and so it can be used in independent applications. The storage can be realized in wide range from byte stream (IStream interface) to files or BLOB fields of DB. The form designer and executing machine are separated so run-time constituent is very small and can be used in any condition from application loading to dynamic swapping of Web page. The next item: the components for the DB handling. Their distinctive features are: network access providing (they can work in distributed environment with local DBMS like Access), high scalability and customizing flexibility (both centralized (the server part of multi-tier application) and dynamic right up to single column parameter managing at the moment of this column visualization). Flexible components of visualization (grid, datafield, combobox) are included here. They have powerful expansion tools and dynamic parameter customizing possibility. Furthermore, these components of visualization can be tightly integrated with DB access components. The designer need all described components to dynamic building of the interface and to professional data presentation (see ascDB). The next tier in the chain of low-level components is the report generator. It allows to create and generate reports on the server. The designer of the generator integrated with designer environment and allows to modify existing reports and to create new reports. Some features (support for unrestricted nested reports, scripting language - VBScript, ActiveX controls-based extendibility and high fidelity) allows to create the integrated reports of professional quality. Such a multilevel structure allows to redesign application based on our technology on any level and with any level of details.

You can win from the component design in a single organization too. By the project decomposing  you can divide a composite component into several simple components. Each simple component can be developed by independent developer and so you can reduce the design-time proportional to the amount of developers. The amount of deadlocks in the final product will be reduced due to the using of public COM interfaces for the interaction between components.

Figure 1. Abstract levels of ASC interaction

Moreover, any product that cannot be extended by independent vendors have no perspectives at the presence. Multilevel structure allows to wedge in any level of details and to complement or modify the algorithms.

Our designer is something average between integrated CASE tool and RAD system, however they have their distinguishing features. In the future such a designers probably will be transformed to separate class of software or will create a new ideology of software developing.

Today we are developing the core - the part, that can have only one realization due to the compatibility requirements. It does not mean that the project is closed. If any company would like to become our partner in this project we'll be glad to discuss any proposal. We are going to create an open forum for  the discussion of all the aspects of this problem.

We are going to reveal the code needed to expand object model. 

Below we'll expound all mentioned aspects more detailed.

Above all let's examine low-level technological aspects like methods of interaction between different components.

We have chosen the Microsoft COM (Component Object Model) technology  as a basic technology. We will not analyze the concept of this technology nor agitate for the COM, but we are going to prove our choisestop briefly .

I'll try to formulate the requirements for the technologies, necessary for the described product design. 

Our first requirement is an ability of the technology to create the components that can be expropriated. "Expropriated" means that the component must support both the dynamic loading and the dynamic binding. It is impossible (or, at least, inconvenient) to create a single product in the geographically-distributed company if this product must be completely recompiled and rebuild every time for a propper work. The product which consists from components (especially from different vendors) can be very large. If all the components are to be loaded in RAM simultaneously, the size of RAM will surely exceed any reasonable limits. The dynamic loading allows to reduce RAM consumption (because there will be loaded only the necessary modules)..

The dynamic loading principle laid in COM from initial (in fact, COM technology was created to realize this principle).

Moreover, we need some standard that allows to create the user interface consisting from different vendors components. ActiveX controls (COM-based, too) made it possible.

The model must support the descriptions of objects and transparent access to that objects from different (at least the most popular) programming languages. These two requirements are also satisfied by COM due to the interface ideology and due to the possibility to describe an interface in type libraries. All the popular languages are supported now: C++, Pascal, Basic, Java. COM provides the technology of the dynamic method invocation, based on IDispatch-interface. IDispatch together with type libraries allows to link objects to script languages (for instance to VBScript or JScript). Type libraries are a beautiful meta-description and this fact is very important for component environment.

And what about network computing? DCOM and its expansion (MTS/COM+) provide full-function support of computing in LAN and in Internet. It provides the execution of the compiled code on another computer. The debugging is simple enough and, if needed, the remote object can be loaded in the address space of an invoking process (for example for the creation of a single- user version).

The selfregistering of COM objects allows to add components to the functioning system.

Microsoft OLE DB (based on COM too) allows to get unified access to different data sources.

COM is not just a standard but it is a standard that is supported by durable etalon realization. 

There are a lot of good technologies and realizations (for example for network computing you can select CORBA) however no one standard cannot satisfy us on the same level as COM.

If the multi-component product must create an impression of monolith product there is not enough to use interacton principles. This product must be build on a common component basis. I mean the data access resources, visual controls, report generator and the designer (some visual environment that allows to join components in a single product). The designer is a part of the core and everything else we shall call the low-level components.

At first we tried to use third-party components (from Microsoft, Borland and other vendors) but the problems outweigh the profit from their usage. Some components did not meet one of our requirement, namely their were too tightly bounded up with specific development tool. Another were too expensive because of license payments when selling products based on that components. And finally almost all of them had a problem with realizing multi-tier model. At long last we decided to create our own components.

We realized three projects: ascDB (the component for DB access in the distributed environment and visual controls that allow to input and visualize data), ascContainer (the container that allows the dynamic creation, saving and loading of forms, consisting from ActiveX controls and script) and ascReport (the component that allows to customize reports, organize preview and print reports, the report generation occurs on the server).

All the components are working in the distributed network environment and supporting a wide range of properties. Some of these properties can be both customized on the server or dynamically changed on the client side.

We did not determine exact prices for these products, however we promise that single-user version will be free. 

We ask everybody who interested in this problem to contact us via e-mail  or to call us at +7(095)180-0201. We'll be grateful for your messages and  responses.

Your comments and suggestions you can send to: mag@rsdn.ru
Copyright © 1994-2016 ООО "К-Пресс"