jcengine framework
hosted by Sourceforge


Configuration engine

The engine represents a class or classes at the heart of an application aimed at constructing sets of instances. The purpose of this element is to store instances that compose a given structure. The second role is to ensure the validity of a given structure.

There are many potential ways of doing this. In the section below I discuss some of the methods that I am aware of.

Provides-consumes

This is probably the simplest mechanism for abstracting the way that components inter-relate. The model relies purely on a simple arithmetic mechanism for calculating the results and validating any added or removed instances. This approach can be simply demonstrated. An instance provides n number of hard disk bays – adding a hard disk will consume n – 1 from the provided value. A hard disk may also provide n value of capacity. The validation occurs at two points. Does this part consume from an existing provider? And secondly does consumption occur within the limitations set down by the provider? A failure of any of these points could result in an error or warning being generated.

The model has the additional benefit that the state of providers can generate useful information. The previously mentioned hard disk capacity is one example. But others could also be generated including weight, power consumption and size.

Declarative Rules

Declarative rules are pretty common currency in most expert systems. They are perhaps more widely known as ‘if-then-else’ conditions. I have some reservations about the use of declarative rules but they do add useful flexibility to any construction model. The main problem is the increased complexity they add to the process of data maintenance and reduce the responsiveness of the engine at runtime. As yet, declarative rules have not been implemented.

Configuration engine implementation

There are several issues that need to be covered when covering engine design. One key area is the how validation is performed when an instance is added or removed from the engine’s cache. There are two basic options: forward validation and rollback validation.

With forward validation a copy of the current cache is made. The instance is added or removed. If the validation tests are successful the copied cache is made current. If the tests fail the copied cache is discarded.

In the case of rollback validation an instance is added or removed directly to or from the cache. The validation methods are fired. If validation fails the actions are rolled back.

Both these methods have strengths and weaknesses. In the current configuration engine I have used rollback validation.

A second key area is designing the engine in terms of notifying non-framework components of its current state and operability. I have tried to resolve this issue by implementing the cache containers using the mediator pattern. For further information I recommend taking a look at jcengine.core.CollectionEvent and jcengine.core.CollectionListener.

Pricing

One of the problems with building an application of this nature is handling the pricing of sales items. This stems from pricing policies. Many companies - especially the larger ones - have different prices for the same item for different groups of consumers. This is one of the reasons why jcengine is a framework and not an application. The current engine design does provide a pricing mechanism but it is reliant on a price supplied by a cached sales item. This price is stored within the instance. A better mechanism will utilise a price supplied by an external source. This implementation remains at the planning stage.

Regionalisation

One of the key features of the original application was its ability to handle regionalisation. One good example of the need for region policies is with power cables. A customer in continental Europe will need a different power cable from a client in America. In the historial application this was solved by ensuring that the client selected a region prior to using the application. This selection created an invisible part instance which was added to the build state of the configuration engine. This invisible part indicated what region the build was designed for. The engine then used a range of declarative rules to construct the region specific parts required. Although this technique worked reasonably well it compromised the simplicity of the product and relied on declarative rules. A new method of regionalisation would be ideal.


Back to main

Java is a registered trademark of Sun Microsystems, Inc. Windows 95 and Windows NT are trademarks of Microsoft Corporation. All other product names and company names mentioned herein are the property of their respective owners.