Cold Fusion Business Layer - CFBL© technology overview

*New*   See how Task management system was produced using CFBL. Read a full story here

Typically Cold Fusion applications or other applications written on scripting languages are tightly coupled with an underlying database. Data manipulations are done directly from the scripts that are available to public. The disadvantages of such a system are following:

• Low level of security because of the availability of database for user components layer
• Low level of encapsulation between the functions, which works only on the user level, and those from system level
• Less maintainability because changes/ additions in underlying data structures yield a dozens of changes to be made on a scripts and otherwise

To diminish the influence between the GUI and database 3-layered applications (GUI layer, Business layer, Database layer) can be introduced. The main aspects of using such an approach are those that we decouple the architecture to less dependent and thus much more manageable items. For example having a business layer interacting with a database we can achieve major savings during GUI design because the data structures that are of practical usage will be already in business objects. Another benefit of using 3-layer architecture is lower maintenance cost that is important for dynamical software such as web sites. Moreover the benefits of 3-layer applications are those that it is possible to fit to changing or incomplete requirements, because this architecture is flexible enough to handle the changes. In practice you can use the non-controversial model of the business layer based on the problem domain, fast and optimized database and GUI that fits to the end-user requirements linked together. As far as those layers come from different areas we can achieve an optimal design for them. Moreover, changes in user interface will evolve only slight changes in business layer and usually no changes to database at all. Thus the level of encapsulation and manageability will be increased.

Below is a short list of reasons you might want to use business layer in your next project:

• Business objects fully insulate clients from business rules, the underlying data storage, and concurrency issues, resulting in complete encapsulation.
• Applications have an open architecture and are fully scalable.
• Applications built with business objects are also much more maintainable. Because of the layers of responsibility applications can be modified more easily when the business needs change.
• Business layer components are implemented as reusable by different web interfacing applications. In can be HTML, XML or WAP clients depending on purpose.

As for the structure of a business layer it is usually consists of two distinct items. The first one is the business objects hierarchy. Business objects fully encapsulate the behavior that is expected from the entity they model. In practice Cold Fusion is not an object-oriented language and even not procedure oriented but we can provide the similar components that will act as objects (tags collections). Of course this system is far from such benefits of using object-oriented approach as polymorphism. But at least it can be thought as less coupled. The second one are business services that supports such common features as transaction management, persistence support etc. The full scale of such a services is well documented in a CORBA v. 2.0 specifications (see CORBA services). In practice only a few can be adapted to the scripting language environments and those services are:

• Security manager
• Transaction manager
• Validation services
• Error handling
• Concurrency manager

CFBGen code generator produces the code for Business tags directly from the Class Diagrams designed using CASE tools such as Rational Rose (in practice any tool that is UML compliant will suit). DDLGen generator is used to produce data definition language statements from the Class Diagram. Another tool is GUIBuilder that is capable to catch the interfaces of the generated Business Tags and map them to the web interfaces.

The structure of the application based on CFBL technology is shown on Fig. 1.

Fig 1. The structure of the CFBL application.

All scripts that are handling user input reside on a presentation layer. Those scripts interact with a business tags layer. Presentation layer scripts can interact directly with the database but only if the operation do not require modification. All other operations are done through Business Layer. Business tags produced by CFBGen takes into account all the relations between objects that are outlined on a Class Diagram. Those tags perform typical tasks as serialization/de-serialization of data structures according to relationships established on a object model. And thus they can take care of data integrity themselves. Someone could ask that the database can handle cascading operation and thus it does already provides a necessary level of data integrity, but from the other point of view sometimes only cascading operations are not enough to handle complex relationships. Powerful databases such as Oracle or MSSQL provides triggers that can be used to perform this tasks, but frequently it is required to perform some tasks that are related to presentation layer when the triggered event occurs (for example cache updates upon change in database) executing this tasks on a database layer fails with encapsulation aspects.

The one of the most valuable benefits of usage CFBL architecture is the ability to map analysis stage results directly into source code at least because analysis stage decisions can be easily verified. Moreover usage of code generation software for all three layers can produce full functioning database backended applications almost within few hours. One can think that this will solve all the problems with software development. But the practice shows that applications built using code generation are far from such quality goals as handy user interface and far from optimal performance. But, nevertheless in complex projects it is usually difficult to say even about the metrics of the final product and thus the result of code generation is quite essential for understanding the real scope of work and clarification of further strategically or tactical decisions because it can easily outline the system bottlenecks. Moreover these results can be thought as a first iteration of a project life-cycle (pre-alpha release of a final product) and can reduce the number of total iterations needed to achieve truly functional and quality solution.

Thus it is clear that the technology such as CFBL is essential for organization of development process and can help building reliable and quality software.

Typical development process for application using the CBFL technology is shown on Fig.2:

Fig 2. Typical development process based on CFBL technology.

As it can be seen the development process is simplified by having business tags and database DDL statements generated directly from Analysis Object Model. Web interfaces provided by GUIBuilder will give a simple interface for data manipulations.

Present implementation of CFBL v 2.0 is capable of generating CFML scripts and data definition statements for MS SQL / MS Access databases.

The further planned extension to this technology is based on BOSS (Business Objects Softomate Schema) technology currently supported by Softomate.

Grebenyuk Oleg
Copyright (c) by Softomate Inc. 1998-2003.
Last revision May 29, 2003.