BS ISO IEC 30106-1 pdf download.Information technology — Object oriented BioAPI — Part 1: Architecture
1 Scope
This part of ISO/IEC 30106 specifies an architecture for a set of interfaces which define the OO BioAPI. Components defined in this part of ISO/IEC 30106 include a framework, Biometric Service Providers (BSPs), Biometric Function Providers (BFPs) and a component registry. NOTE Each of these components have an equivalent component specified in ISO/IEC 19784-1 as the OO BioAPI is intended to be an OO interpretation of this part of ISO/IEC 30106. For this reason, this part of ISO/IEC 30106 is conceptually equivalent to ISO/IEC 19784-1. Concepts present in this part of ISO/IEC 30106 (for example, BioAPI_Unit and component registry) have the same meaning as in ISO/IEC 19784-1. While the conceptual equivalence of this part of ISO/IEC 30106 will be maintained with ISO/IEC 19784-1, there are differences in the parameters passed between functions and the sequence of function calls. These differences exist to take advantage of the features provided by Object Oriented Programming Languages.
5 Object Oriented BioAPI architecture
5.1 Summary of BioAPI architecture Object Oriented BioAPI shall be defined in a way that allows both structured development of applications and services, as well as interoperability between application and BSPs, and among BSPs. Therefore, the definition has to be done respecting the hierarchical structure of BioAPI (19784-1). In few words, an application shall be developed using an OO BioAPI that allows the instantiation of a BSP, which is based on the instantiation of one or several BioAPI_Units. The BSP can host more than one BioAPI_Unit of each category, and several units of each type can be used at any time, no presenting any kind of limitation on the units to be used in a BSP. This makes it necessary for all methods to provide the reference to the unit to be used in each of the operations. An application is not permitted to directly access BioAPI_Units. Therefore, this part of ISO/IEC 30106 does not define a BioAPI_Unit interface, but only an object oriented hierarchical interface/class model that may ease the implementation of the BSP. The BSP shall inherit all public methods and data structures for each BioAPI_Unit the BSP encapsulates. It is the responsibility of the BSP’s implementation to determine which functions of the BioAPI_Unit are offered to clients of the BSP. Note, an exception should be returned for any BSP interface method that is not implemented in the BSP. This is represented in Figure 1.Programming an application, which interacts directly with a BSP, introduces practical considerations for the application designer. One such consideration is dealing with third-party suppliers who provide biometric components for use in applications. For example, a supplier of sensors may desire to include support for their entire family of sensors as a single entity (e.g. a library). To achieve this, the supplier may consider implementing the library as a single BSP, but may choose to not implement monolithic methods (i.e. aggregated functionality such as Enrol, which does in one single call the capture, the processing of the sample, the creation of the biometric reference and even the archiving). Without monolithic methods, the BSP forces the application to take responsibility for the implementation of monolithic style functionality. This situation means the BSP may pass biometric data back to the application so the application may perform processing. The application may then need to pass this data on to another BSP for additional processing. In some contexts, the passing of data out to an application may simply be inefficient, in other contexts this may be a security concern. A possible solution for this inconvenience is to allow the hypothetical sensor BSP to interact directly with other BSPs, rather than involving the application in the management of this communication. To achieve this, the biometric product provider may create an entity (e.g. a library) containing several BioAPI_Units of the same kind. This is called a Biometric Function Provider (BFP) and exhibits the following characteristics. — The BFP shall only host BioAPI_Units of the same category. — The BFP is meant to allow that a BSP is linked to one of its BioAPI_Units, in order to complete or adapt the functionality of the BSP. — The BFP shall not provide functionality directly to the application, but only link to the BSP. The BSP communicates with the BFP on behalf of the application. The BSP is responsible for providing the BFP’s functionality to the application. The above mentioned situation also solves a problem from developers’ point of view, which deals with simplicity in developing applications. If an application may require to use BioAPI_Units from different providers (e.g. a sensor from one provider and processing, comparison and archive BioAPI_Units from other provider), then it will have to load two different BSPs, calling each of the methods independently. As mentioned earlier, this has the inconvenience that it won’t be possible to call a monolithic method, such as Verify(), which performs the data capture, the processing, extraction of the biometric reference from the database, the comparison and taking the decision, all within the same single call. Then, the application programmer will have to know which individual methods have to be called from each of the BSPs, in order to get the same functionality. To summarize, a level of abstraction and efficiency is achieved through the use of BFPs to segregate functionality into discrete sets. Each BFP aggregates a set of functionality provided by a product supplier (through a BioAPI_Unit). These BFPs are used by a BSP, where the BSP combines functionality from each BFP to offer monolithic methods for use by a client. The client application may then call the monolithic methods in the BSP without concern for the underlying implementation offered by a product supplier.
BS ISO IEC 30106-1 pdf download
