Technical Implementation Methods

Data Access Methods

ABIF provides access to biodiversity data using standard exchange formats and protocols. This data is distributed across a number of external data providers, including both biological collections (museums and herbaria) and government agencies. Data is accessed through web services based on GBIF-specified interfaces and standards (where available and as far as possible). Each web service uses an XML-based data standard to maximise the reusability of the resource. It supports requests for subsets of records held within the data set and each record returned should be identified by a unique identifier and timestamp (but this is currently optional). All data records include information identifying the owner or provider of the record and this information is retained as part of the data.

While ABIF holds no primary data itself (this data being held remotely by its owners, with the exception of hosted datasets) ABIF will index the holdings of data sources. These indexes are used to increase performance when locating relevant information, the details of information items then being retrieved from remote sites and reported. Indexes are updated regularly to maintain currency and are not visible to outside users, these users only seeing remotely held data. It should be noted that the use of indexes is optional and is provided only to enhance performance.

Tool Access Methods

While access to data is a key component of ABIF, access to tools to work with this data is arguably just as important (or even more important!). ABIF supports two methods for linking data retrieval and data analysis: direct transfer of data using an HTTP POST call and the use of a data sharing service.

Directly calling a web site using an HTTP POST to transfer data is the classic web method for building web sites. This is a well documented and understood method and is almost universally used across the Web. ABIF supports this method of linking data with tools. It is the preferred way that search methods and analytical tools are developed as a unified package by a single development team.

However, the spirit of GBIF (and therefore ABIF) is to foster collaboration across the broadest possible range of users, including users who we are unaware of or who have yet to be identified. For this to be achieved, ABIF must combine open data standards with flexible methods for data sharing. This is done using community accepted XML-based data standards and SOAP-based communication methods. ABIF fully supports the data standards recommended by GBIF (where they exist) and works with groups such as the Taxonomic Database Working Group (TDWG) to develop new standards (where they currently don't exist). ABIF also provides a method of "parking" data from search results in a central location which is accessible to analytical tools. This "parking" area is independent of the search methods or analytical tools being used, thus allowing essentially any search method to locate information which can then be passed to any analytical tool, without either knowing anything about the other. Thus collaborations can be developed which are truly open, with each collaborator concentrating on their strengths and users being able to "mix and match" components which best meet their individual needs.

Development Methods

The primary programming language for ABIF core components is Java (specifically J2EE? with the Eclipse development environment). However, given that "ABIF" is a collaborative project which exists in a highly distributed environment, this choice cannot be centrally enforced and any number of other languages are used on a case by case basis.

Database use (where required) is based on "plain vanilla SQL" without use of database-specific features and/or functionality. Ideally all modules are tested against both MySQL? and local solutions (if they differ). For example, DEW/ABRS use Oracle as a departmental policy and do not support other databases in production environments. As such the current ABIF system runs against Oracle. However, modules will be tested, as far as possible, against MySQL? to ensure portability.

All modules have both native and SOAP interfaces. Native interfaces (classes, methods and properties) are used in local developments while SOAP interfaces provide external access to this same functionality. This combination gives the advantage of the speed and flexibility when working locally while supporting broad access in a highly distributed environment.

Project and Source Code Management

We are using FishEye? to manage the ABIF source code. FishEye? supports the inspection and searching of source code together with a change history. For bug and issue tracking, we're using JIRA. In addition managing issues JIRA can look at the CVS tree for changes applicable to a given bug. Combined these are powerful tools for managing ABIF development.

ABIF

GBIF

News

Edit • Attach • Print version • History: r3 < r2 < r1 • Backlinks • View wiki text • Edit wiki text • More topic actions