The lowlevel API represents the basic interface to the BioID services. According to the structure of the BioID kernel it is divided into three parts: the Client Peers which provide access to the client services and to the Server Peers which in turn enable access to the server services. The third component is the Server API, that is used by administrative applications to access BioID data, that is not accessible by the Server Peers due to security reasons.
The Client Peers are the entry points for the user interface layer. Typical BioID applications have to use these peers for any interaction with the BioID kernel. There are two peers: the ClientPeer and the DataPeer. These peers are implemented within the BioID Client service.
The ClientPeer represents the interface to the BioID Client and is used to access any client settings and to run BioID specific tasks, such as Record, Verify or Identify. For an identification or a verification task the ClientPeer will connect to a BioID Server which actually performs the classification. For the communication to the client application a callback interface is used that has to be implemented by the client application. The callback interface informs the client application about the state of the BioID Client and currently running jobs, reports errors and delivers live data and features. Note that the BioID Client internally uses job queues which run in their own threads, so events are always sent to the client application asynchronous.
The DataPeer implements two different tasks: it connects to a BioID Server and makes the Local Classifier available. With the server connection you can fetch and partially modify information and data of the users stored in a database. The Local Classifier can be used to perform a local verification of a single user without the needs of a BioID Server connection. But note, that the client is not able to store any data. To use the local classifier, an application has to provide the needed data itself.
The Server Peers are accessed from the Client Peers or can be used directly by server side applications such as WEB services. They are subdivided into two peers: the ServerPeer is responsible for the classification tasks, identification and verification and the DataServerPeer which provides the ability to access user specific data, such as user information, user patterns and templates. The server peers are implemented within the BioID Server service.
For administrative needs enhanced access to the BioID database is needed. Two ways are provided to perform administrative tasks: a data access object implemented within the BioID server and direct programming of the BioID database using OLEDB, ADO or SQL scripting. The data access object is accessible only by BioID Admins, so an administrative application such as the BioID management snapins must be executed using an account that is member of the BioID Admins group. This is an inevitable requirement to protect the biometric data in the database from unauthorized access.
Note: due to the mentioned security issues and because we made the experience that programmers tend to use this object very generous, we decided not to make the object public at the moment. We instead are currently implementing a few "wrapper" objects for easy and secure access to the BioID data access object.
Some administrative tasks can also easily be done by using direct database programming. In this case security issues are not a problem due to the usage of the security architecture of the underlying database management system. Please refer to the description of our database structure for more details of how to program the BioID database.