Abeans are extensive set of tools which helps developer efficently write good applications that follow standard programming and behavioral rules Third generation of Abeans was breed on experiences Cosylab team has gained by writing many applications for various accelerator labs with connection to various distributed control systems. Having a pluggable model of control systems, Abeans are applicable to any control system from EPICS, CDEV, TINE, TANGO, ACS to proprietary ones.
Abeans features target all aspects developer has to solve to write powerful, reliable and feature rich applications. They provide solution for resource loading, lauching, configuration, connection and lifecycle management, GUI widgets and wide assortimant of utilities and helpers for common tasks.
Abeans provide the building blocks for constructing an object-oriented representation of some complex system. A model is a set of Java classes that represent the components of a given system, and those classes are common to all systems from a certain functional / problem area. In other words, in order to control physical devices such as power supplies, vacuum pumps, etc., Abeans declare, for each physical device, an object instance in the OOP sense, and define the lifecycle, containment and relation to other services.
The fist model that was implemented was the Channel model ? the remote data is accessible through separate channel objects and is well suited to model systems that are flat (not organized hierarchically), like for example in EPICS or TINE protocols. There is one model for all channel based systems (not a separate model for TINE channel, and EPICS channel).
The second is the BACI model ? here a set of properties can be part of a hierarchical entity, for example a device, that mirrors the logical structure of physical devices, like power supplies. The main point is that the device is a Java object. This model was primarily developed for ESO and uses ACS CORBA plug below it.
Abeans usually communicate with some already existing software that offers access to the data. A plug is that part of the Abeans system that is responsible for translation of requests originating in Abeans (in GUI, services, etc.) to a communication protocol used by the controlled system.
So far, we have implemented plugs for TINE protocol for DESY at Hamburg, EPICS plug that communicates to the JCA library, UFC plug for the protocol used at GSI, and ACS CORBA plug for ESO.
Although two Abeans applications that use two models for the control of two software systems differ in their basic purpose, they still contain a lot of shared functionality. Error reporting, logging, resource loading, configuration management and similar tasks can be delegated to a body of shared services, which is implemented once and for all. This approach reduces the amount of coding and guarantees consistent behavior, look and feel and similar functionality across all applications developed with the Abeans framework.
So far we have implemented the following services: configuration service, data resource service, debug service, exception handler service, report service and thread pooling service.
Abeans also offer standard interfaces for access to distributed services (i.e. services provided on remote machines), such as distributed naming service, or a distributed archive. We used existing technology where possible: for example, access to object directories (such as TINE Name server or ACS Manager) is done through standard JNDI (Java Naming and Directory Interface). Consequently, it is possible to develop a directory browsing Abeans application, which will run on all Abeans plugs ? this is the Object Explorer. Similarly, distributed archive service can access archive data in remote archive servers. Archive reader application developed for DESY uses this service of Abeans. However, since the same service will be implemented for EPICS as well, we will be able to reuse the same application to access EPICS archives.