VpPuZzle. Observe. Part 2

Автор: Виктор Юхтенко

VpPuZzle. Observe
Part 1 Part 2

Pzl-system

All features of the PZL mechanism are provided by the Pzl-system. Pzl-system contains some classes represented as source code and some classes represented as the statically linked libraries. It was used the feature of Visual Prolog that the source code of libraries can be written in Visual Prolog language. The picture below shows the content of the PzlSystem for the executable entiry (EXE).

And the picture below shows the content of the PzlSystem for the DLL

The difference is in the libraries and in the package pzlPort.pack, which used in the case of application. There is no need to remember all these files – the Pzl-technology tools can generate the project for the DLL and any VIP application project can be easily modified to support the Pzl-technology. The name PzlPort was chosen for the core of the PzlSystem, which must be included to the application project.

The PzlPort is responsible for the loading and unloading DLLs. When user calls the pzlComponent constructor, PzlPort finds the DLL, which contains the appropriate pzl-component. If the DLL is not already loaded, then it loads the DLL and communicates with the classes of the pzl-container.

The PzlPort uses the order as follows:

• Local user defined registration file
• Current User at Windows Registry
• Local Machine at Windows Registry

The pzl-technology uses the same principles to support the lifecycle for classes. When the instance of the class is not needed, then all references to this class must be removed. PzlPort is responsible to unload the appropriate DLL, when there is no pzl-components in use. This happens, when the Visual Prolog garbage collector removes the instance of the class.

Thus User has no deal with the DLLs and has the deal the only with classes the same way as it would be using the standard VIP programming style

Compatibility and Authorising

Because of the parts of the applications, based on the pzl-Technology, may be build in different time and with the different versions of the Visual Prolog, the incompatibility between the application and DLLs and between DLLs may happen. Tools placed to pzl-port and pzl-container libraries communicate and check this compatibility before the use of components have started.

If the incompatibility have descovered, then the DLL is unloaded and the exception is generated.

Also three levels of the licenses are used to avoid the unauthorized use of pzl-containers. These levels are:

1. Public
2. Commercial
3. Exclusive

PzlPorts may have Commercial and Exclusive license levels, while pzl-containers may have all three levels listed above. The Exclusive license level has the highest privilege.

The PzlPort can communicate with the pzl-containers, which have the same or the lower privilege.

The Exclusive license level is the private license and can be created for the given user personally.

The PzlPort, which has the Exclusive license level of the given edition, can communicate with the pzl-containers, which have the same edition of the Exclusive license level.

The use of the pzl-containers with the Public and Commercial license levels is available also in that case.

Active Objects registration

PzlSystem performs some functionality, which are not directly concerns with the component technology.

One of these kinds of the functionality is the Active Object registration. Let’s come back to the major construction of the VIP:

...
   MyClassInstance =myClass::new() 
   MyClassInstance:callNeededPredicate(…), 
...

Once created instance of the class will be destroyed if the pointer (reference) to the instance will not be stored. There are many situations, when one instance may be used by many other classes. Then it is needed to store the pointer to this instance in the place, which all components can easily reach.

When we have the application built using the usual style we may have the static class, which can store pointers to instances. When we use the technology based on the DLLs we need some data store, which all components can refer to. In the pzl-technology the special data store engine embedded to the pzlPort. Any component placed to any container can easily make the operation like

  MyClassInstance =myClass::new(), 
  pzl::register(“MyClassInstance1”, MyClassInstance), 
  MyClassInstance:сallNeededPredicate(…), 
...

Any other object can get the object using the call

...
  Object =pzl::getObjectByName_nd(“ MyClassInstance1”),
  !,
  MyClassInstance=tryConvert(iMyClass, Object), 
  MyClassInstance:сallNeededPredicate(…),
...

Class Pzl contains many other useful predicates to manipulate with the object registration.

If we follow the idea of the open architect applications, then the user-defined component may have an access to all components active in the application at the moment. The only condition is that User must know the interfaces of the classes in this case and User must know the principles of the organization of the application.

Общее пространство обработки ошибок

Другим механизмом, не обусловленным непосредственно pzl-технологиеей, является огранизация общего механизма обработки ошибок для всех активных Vip7DLL. Таким образом, информация об ошибках, созданная средствами обработки исключительных ситуаций VIP7, доступна для обработки в любом из классов приложения.

Общий поток вывода STDO

Все компоненты, активные в данный момент, используют единый стадартный поток вывода.

Заключение

Для создания технологии работы с DLL были использованы следующие свойства системы программирования Visual Prolog:

• Возможность использования детерминированных и недетерминированных предикатв, вызываемых из DLL
• Главное приложение и DLL работают в одном и том же пространстве памяти
• Пакетная организация исходных текстов
• Гибкая концепция объектно-ориентированного программирования
• Гибкая концепция интерфейсов, интегрированная с концепцией доменов
• Наличие домена object, являющегося родительским доменом для всех объектов
• Локализация констант в классах
• Условная компиляция
• Возможность построения статических библиотек

Pzl-Технологии присущи все преимущества и недостатки, присущие системе программирования VIP, поспольку она не нарушает стиль программирования, присущий программированию в VIP.

Pzl-технология имеет ряд ограничений:

• Возможность использования только одного конструктора
• Все взаимодействующие классы должны быть динамическими классами, то есть классами, порождающими объекты
• Имя класса и имя базового интерфейса должны раличаться
• Будучи помещенными в DLL, pzl-Компоненты могут быть вызвваны только приложениями, которые используют pzl-технологию и созданы с использоанием средств системы программирования Visual Prolog

Следующие ограничения, характерные для применения DLL в VIP, должны быть приняты во внимание:

• Компоненты, основанные на DLL, должны иметь стабильный набор интерфейсов. После того, как DLL построена, любые изменения в используемых интерфейсах могут привести к прерываниям по ошибке. Для избежания этого все компоненты, взаимодействующие с модифицированной компонентой должны быть перестроены.
• DLL, построенные с использованием VIP, пользуются библиотеками периода исполнения, поставляемыми в составе системы Visual Prolog. Эти библиотеки зависят от версии VIP. Любые модификации в этих библиотеках периода исполнения, связанные с изменениями версии VIP могут вести к нестабильности приложения. Во избежание этого рекомендуется все компоненты перестроить с использованием новой версии системы программирования.

Опыт применения

VpPuZzle. Observe
Part 1 Part 2

Создан полный набор операций для манипуляций pzl-Компонетами и pzl-Контейнерами. Первая версия приложения, которое поддерживает элементарный набор операций (Elementary Studio), позволяет использовать PZL-технологию в практическом программировании. Инструменты, которые поддерживают PZL-технологию, сами используют эту технологию и, таким образом, следуют идее приложений с открытой архитектурой.