BioAPI 2.0 - Detailed Description
Introduction
There are two different versions of BioAPI. One is an American National Standard (ANSI/INCITS 358-2002, also known as BioAPI 1.1). The other is an International Standard (ISO/IEC 19794-1:2005, also known as BioAPI 2.0).
The BioAPI 1.1 standard contains the same text as the BioAPI 1.1 specification originally developed by the BioAPI Consortium. The BioAPI 2.0 standard is a completely new version developed by the international standards committee for biometrics within ISO (ISO/IEC JTC1 SC37).
There are many differences between BioAPI 1.1 and BioAPI 2.0. The old component model of BioAPI 1.1 (which can be described in terms of an application interacting with one or more BSPs through a framework) has been retained but extended. There are several important new features, but some BioAPI 1.1 features have been removed in BioAPI 2.0 for various reasons. In other words, BioAPI 2.0 is the result of a series of simplifications and enhancements made to BioAPI 1.1.
All those simplifications and enhancements were made taking account of feedback received from the users of BioAPI 1.1 (including BSP developers and application developers) both before and during the work on the new standard within SC37. This was made possible by the involvement in that work, as National Body delegates or experts, of many people who had been, some time earlier, key players in the development of BioAPI 1.1 or - more generally - in the activities of the BioAPI Consortium.
We believe that the new standard is more useful and more powerful, but also more usable and more interoperable than its previous version. An example of a new feature is the ability for a BSP to delegate part of its functionality to a separate component (called a biometric function provider, or BFP), thus enabling a separation of capabilities into separate software products. An example of an old feature that has been removed is the streaming callback mechanism that enabled BSP-to-BSP communications.
Differences between BioAPI 1.1 and BioAPI 2.0
The Component Model
The main difference between the two versions of BioAPI is in the component model.
The component model of BioAPI 1.1 is comprised of a framework, one or more biometric service providers (BSP's) "below" the framework, and one more applications "above" the framework.
NOTE - The Reference Implementation of the BioAPI 1.1 Framework supports exactly one application for each instance of the framework. An instance of the framework cannot exist without an application that loads it into its memory space, and multiple BioAPI applications use separate instances of the framework. If two applications request to load the same BSP, a separate instance of the BSP will be created independently in each application memory space.
BioAPI 1.1 specifies two APIs, one exposed by the framework to the application (called the BioAPI API), another exposed by the BSP to the framework (called the BioSPI API). Some functions are unique to either APIs, but most functions of the BioAPI API have an identical counterpart in the BioSPI API.
The component model of BioAPI 2.0 is similar, but there is an additional layer of components below the BSPs, called biometric function providers (BFP's). The purpose of a BFP is to take over a part of the functionality of a BSP, enabling a division of work between the two kinds of components.
There are four categories of BFPs, each corresponding to one major subset of functionality of a BSP:
a) Sensor BFPs - responsible for managing sensors, which are usually physical devices capable of capturing a biometric sample from a subject;
b) Archive BFPs - responsible for managing access to a template database, which may be contained in a physical media such as a smart card, or accessible via a logical connection to a relational database management system, or accessible via any other suitable means;
c) Processing-algorithm BFPs - responsible for processing biometric samples, converting them from "intermediate" to "processed";
d) Matching-algorithm BFPs - responsible for comparing a biometric sample against a biometric template and returning a score.
Like BioAPI 1.1, BioAPI 2.0 specifies two APIs, one exposed by the framework to the application (called the BioAPI API), another exposed by the BSP to the framework (called the BioSPI API). Some functions are unique to either APIs, but most functions of the BioAPI API have an identical counterpart in the BioSPI API.
However, in BioAPI 2.0 there is an additional level of APIs that are exposed by BFPs, and are called "function provider interfaces" (FPI's). Unlike the BioAPI API and the BioSPI API, these FPI's are not all the same, but a different FPI is specified for each category of BFP.
BioAPI 2.0 is a multi-part standard (ISO/IEC 19794). Part 1 is what is normally referred to as "the BioAPI 2.0 standard", but Part 1 does not specify any FPI, although it specifies the component model and defines the four categories of BFPs. Additional parts of ISO/IEC 19794 will specify the FPIs for the other categories of BFPs. At the time of this writing (early 2005), the international standards committee SC37 is developing the first FPI - the Archive FPI - as Part 2 of ISO/IEC 19794.
Here are some examples of components that the new model supports:
- A specialized component (BFP) that handles capture (supporting one kind of sensor or multiple varieties of the same sensor), and that can be used with BSPs that know nothing about that sensor;
- A specialized component (BFP) that implements a processing algorithm and a matching algorithm for some biometric modality, and that can be used with BSPs produced by sensor vendors having no interest or expertise to implement biometric algorithms;
- A specialized component (BFP) that handles access to a template database maintained within a physical media (such as a smart card) or a database management system, and that can be used with BSPs that lack built-in support for database access;
- A generalized BSP lacking either sensor support, or biometric algorithm support, or database support, but capable of using a BFP providing that support.
NOTE - It is not expected that all BSPs will be splittable into a totally generalized BSP and a set of BFPs. Although the new component model enables an important division of work among separate components in many practical cases, there will be cases in which a separation may not be possible (or would reduce performance). For example, a BSP that does identification may rely on a tight integration between database access and a matching algorithm, which might be unachievable if these two functionalities were removed from the BSP and delegated to separate components. However, it might be possible to remove all capture-related functionality from that same BSP, and have it rely on a BFP to perform capture instead. In this way, that BSP would not be tied to a particular sensor, and would be able to use any sensor that is supported by a BFP.
Attach sessions, devices, and units
In BioAPI 1.1, an application must "attach a BSP" (previously loaded) before it can call any functions that perform operations such as capture, verification, and so on. The application must "detach the BSP" when it is done with it and before unloading it.
BioAPI 1.1 supports multiple "devices" (normally associated with biometric sensors) managed by a BSP, and a "BioAPI_ModuleAttach" call must indicate which device is to be used in that session (or use a value of zero to indicate default, which is not clearly standardized). Processing and matching algorithms are a built-in capability of a BSP and are not selectable by the application. Database access (whether a smart card or a database management system is used) is also a built-in capability of a BSP and the type of media (or logical connection to a database management system) is not selectable by the application.
NOTE - With regard to database access, a BioAPI 1.1 BSP implementer can achieve some flexibility by utilizing the database name in a "BioAPI_DbOpen" call to identify the media (or logical connection to a database management system) in an implementation-specific manner. A BSP implementer can also exploit the device ID parameter to select some implementation-specific options in the use of the sensor or in the use of the biometric algorithms. However, these solutions are clearly outside the scope of the standard and will not work when a BSP is replaced by another BSP from a different vendor.
In BioAPI 2.0, the concept of "device" has been replaced by the new concept of "unit" that is a generalization of the former. There are four categories of units:
a) Sensor units - representing sensors, which are usually physical devices capable of capturing a biometric sample from a subject;
b) Archive units - representing an access path to a template database, which may be contained in a physical media such as a smart card, or accessible via a logical connection to a relational database management system, or accessible via any other suitable means;
c) Processing-algorithm units - representing an algorithm for processing biometric samples, converting them from "intermediate" to "processed";
d) Matching-algorithm units - representing an algorithm for comparing a biometric sample against a biometric template and returning a score.
NOTE - There is a direct correspondence between the categories of units and the categories of BFPs (see above).
A BioAPI 2.0 BSP can support multiple sensors, multiple "archive" media, multiple processing algorithms, and multiple matching algorithms. Units are the logical entities that represent those real-world things within BioAPI.
In BioAPI 2.0, an "attach session" is a set of units, containing at most one unit of each category.
NOTE - For example, given a BSP that supports two sensor units, two archive units, two processing-algorithm units, and two matching-algorithm units, an application can create an attach session consisting of one sensor unit and one processing-algorithm unit, and another attach session consisting of one processing-algorithm unit, one matching-algorithm unit, and one archive unit. An attach session cannot contain two units of the same category (for example, two sensor units).
In BioAPI 2.0 as in BioAPI 1.1, an attach session is needed before the application can make a call to a function such as "BioAPI_VerifyMatch." However, the attach session is no longer considered as a state of the BSP (as it was in BioAPI 1.1), but moreso as a set of resources (tied to the units being selected) that are to be used in a biometric operation.
In BioAPI 2.0, "BioAPI_BSPAttach" is called with a list of unit IDs. Each unit ID may either explicitly identify a unit (of a given category), or implicitly identify a "default" unit (asking the BSP to choose the one it prefers), or indicate that no unit of the given category is to be included in the attach session.
Registry, installation of components, enumeration of available components
In BioAPI 1.1, there is a Registry containing information about the framework, information about the available BSPs ("BSP schemas"), and information about the available devices managed by those BSPs ("device schemas"). However, there is only one BioAPI function that accesses the Registry. This function ("BioAPI_EnumModules") returns BSP schema information for all available BSPs. There is no function that returns information about the available devices.
In addition, although the BioAPI 1.1 standard requires BSP installers to post information about the BSP to the Registry, there is no standard function or mechanism that supports that posting. The absence of such a standard mechanism in BioAPI 1.1 is problematic, because:
1) It forces other potential implementations of the framework to implement the Registry in exactly the same way as the Reference Implementation implements it, thus adding unnecessary complexity to those potential implementations;
2) It forces BSP implementers either to link their code to binary libraries provided as part of the Reference Implementation, or even to emulate those libraries, in order to be able to post BSP schema information to the Registry as required by the standard.
In addition, since there is no standard function that returns device schema information or framework information, any application developer that needs that information needs to link their code to binary libraries provided as part of the Reference Implementation, or even to emulate those libraries, in order to be able to access the information they need.
In BioAPI 2.0, the whole issue has been addressed and solved in a simple and interoperable way. The Registry is now considered totally hidden within the framework and accessible only via a small number of standard functions. The BioAPI API includes functions for installing and uninstalling BSPs and BFPs ("BioAPI_Util_InstallBSP" and "BioAPI_Util_InstallBFP"), so that installation programs do not need to be concerned with how the Registry is implemented. The standard also specifies a complete set of functions returning information about all available BSPs ("BioAPI_EnumBSPs"), about all available BFPs ("BioAPI_EnumBFPs"), and about the framework itself ("BioAPI_GetFrameworkInfo").
The only users of the standard who will need to be concerned with the internals of the Registry (or use binary libraries) are those who will implement the framework. Application implementers, BSP implementers, and BFP implementers will never need to access the Registry other than via standard functions.
Other differences
There are a number of other (less important) differences. Some are only a change in terminology, others are more subtle. Here is a partial list:
- The conformance clause now specifies new conformance subclasses;
- Streaming callbacks and BSP-to-BSP communications have been removed (they were heavily underspecified in BioAPI 1.1, and there is no significant record of actual use of this BioAPI 1.1 feature by BSP implementers and application developers);
- A "cancel" function ("BioAPI_Cancel") has been added, enabling an application to cancel a lengthy operation (such as a capture) as necessary;
- The numbering of error codes has been simplified;
- A few functions have been added ("BioAPI_SetIndicatorStatus", "BioAPI_GetIndicatorStatus", "BioAPI_Calibrate", "BioAPI_ControlUnit", etc.);
- In the database functions, the term "cursor" has been replaced by "marker";
- In many functions, the term "module" has been replaced by "BSP" (there are two kinds of "modules" now, BSPs and BFPs);
- The linkage of BSP functions is now totally dynamic, and a function address table is not provided as output from "BioSPI_BSPAttach."
Migration to BioAPI 2.0
There are many good reasons for BioAPI 1.1 users to migrate to the BioAPI 2.0, the new International Standard. A quick scan of the differences between the two versions (discussed above) should already provide sufficient motivation for a change.
Another (equally compelling) reason for migration is that BioAPI 2.0 is the foundation of much ongoing standardization activity within SC37, and other standards (including biometric profile standards) are being layered upon BioAPI 2.0 and require its use.
As an example, the Biometric Interworking Protocol (BIP) standard (ISO/IEC 24708) extends BioAPI 2.0 to enable an application running on a machine to use a BSP running on a different machine as though it were running locally.
As another example, the BioGUI amendment to BioAPI 2.0 provides an enhanced GUI callback functionality and enables an application to closely control the low-level flow of a complex enrollment operation driven by the subject (or by an enrollment supervisor, or by both). The BioGUI amendment will be integrated with the Biometric Interworking Protocol (BIP) to support both the subject and a remote supervisor interacting with the BSP during enrollment.
For more information, please contact us at 1-888-OSS-2761 (Toll free USA
and Canada), +1-732-302-0750 (International), or email us at info@biofoundry.com.
For technical support, please e-mail us at biosupport@oss.com.
For more information about the BioAPI Consortium and BioAPI 2.0, please visit
www.bioapi.org.
.:. Top
Copyright © 2009 OSS Nokalva, Inc. All Rights Reserved.
