Next

Introduction

Business applications as described by Microsoft should follow the so called 3 Tier organization. It is interesting to see how it fits to CAD applications.

The top one is the User interface and interaction. It is the client level of a client server application. For CAD this imply local rotation, picking, showing forms and validating entries.

The lower level is the database access. Persistence, transactions etc.. The real model. It can be placed o a different machine to allow multiple user to communicate and work on the same product. This possible today with the granularity of the part. The Data level offer also services to keep the consistency of data like to update NC files if the model is changed or at least to ensure that someone will do it.

The middle tier don't have user interface or individual peristency support. It encapsulate complex operations on data, driven by information from the top level. This is a good place for CAD algorithms like booleans, model computation, part libraries etc..

Transaction Support

In the Microsoft model theses components support transcation server (MTS). Of course in business applications one understand what is the meaning of a transaction. Because these application are usually based on top a Relationnal Database supporting transactions (The low level) most of the burden of transaction rollback support is supported by the relationnal database. Most CAD systems use now structure similar to object Database with a far structure or performance.

Also CAD models must support versionning. In the case of a global database this is only possible if all the level of granularity supports versionned links.

If the lower tier don't supports multi level transaction it will be the task of the middle tier. Most general components which don't want to rely on what the lower level support will have to take care of rollback.

Interface for Middle Tier Components

In classical programs middle tier are procedure or short term objects. It is interesting to keep this procedure semaphore for Middle Tier objects. There for we recommend that components carry multiple interfaces.

Dispatch Interface

This interface will carry all options of the components as properties. For a pocketing component this will be all paramaters like covering ratio, tolerance..

This interface may also support the effective execution of the procedure. This function will always be called Run() with no parameters.

Function interface

So that mixed is not possible this interface support only one shot functions. There may be multiple functions declared if the components supports variable type of parameters or return.

Support for associativity

 

Components Anything that can be used to produce end user level applications.