# Presentation: 182554

## Identifier Services FrameworkArchitecture & Design Overview

*caBIG Architecture Workspace*
*Teleconference June 30, 2006*
*Frank Siebenlist - franks@mcs.anl.gov*

## caGrid’s Identifier Services Framework

- Identifier
- “Naming” of individual Data-Objects
- Globally Unique Name for each Data-Object
- Services
- Create/modify/delete name-object bindings
- Resolve name to data-object
- Framework
- Provide for Trust Fabric => Binding Integrity
- Policy-driven Administration => Curator Model
- Fully Integrated with caGrid’s Architecture and Implementation

## Why (Standardized) Data-Object Identifiers?

- Efficiency
- Passing by reference vs by value(Data-Object can be many Mbytes)
- Data-Object Equality test through String comparison(inequality test is no requirement...)
- Consistency
- Standardized way of referencing objects
- Standard identifier => data-object resolution mechanism
- Meta-data binding to standard object reference
- Well-known primary/foreign key for (distributed) JOINs
- Name for policy expression for data-object access
- Name for audit entries about data-object related activities
- ...
- Possible correlation of all of the above...

## Data-Object Identifier Properties

- Identifier is a String
- Identifier is a forever globally unique name for single Data-Object
- Identifier can be (globally) resolved to associated Data-Object
- Data-Objects are immutable, almost immutable or mutable...
- Identifier value “meaningless” opaque string for consumer
- Resolution information embedded in Identifier Name
- Only meaningful for resolution service related components
- Identifier is a Universal Resource Identifier (URI)
- URI-schema will be made completely transparent from Identifier producing applications and consumers.
- ”bigid:” - at least until we have learned more about its usage...(... and to avoid distracting schema-choice discussions)

## Identifier Usage Model

## Naming Authority, Identifier Curator, Data Owner and Identifier User

- Naming Authority (NA)
- Guards integrity of identifier namespace & bindings
- Maintains identifier to data-object’s endpoint mapping
- Conceptually equivalent to caDSR...
- Identifier Curator/Administrator
- Understands semantics/access of data owner’s objects
- Trusted by NA to administer binding for certain identifiers
- Administers identifier to data-object’s endpoint binding
- Data Owner
- Provides access to data-objects through “endpoint-references”
- Identifier User/Consumer
- Trusts an NA for certain identifier bindings
- Uses 2-step resolution to obtain data-object(identifier => endpoint => data-object)
- (In-)Directly trusts Data Owner for data-object integrity

## Identifier Services Framework Requirements

- Fully integrate with caGrid Architecture and Implementation
- WS-Interface specifications and implementations:
- Naming Authority, Identifier Curator and Data Owner Services
- In practice, co-location option of Curator/Data- or NA/Curator/Data Services makes sense
- Java APIs to accommodate co-located functionality
- Abstract as much as possible of framework intrinsics, resolution, and naming schema from identifier producers and consumers
- Ideally it should be a transparent infrastructure service
- Support (secure) Data-Object migration, replication, caching...
- All requirements for truly distributed deployment
- Solid Trust Fabric for Identifier Administration and Resolution
- Success stands or falls with integrity of the underlying framework...
- Leverage existing Identifier framework implementation
- where possible and where it makes sense (Handle System, LSID)

## GGF’s WS-Naming RequirementsEPR Minter & Endpoint Identifiers

## GGF’s WS-Naming Requirements EPR & Identifier Consumer

## GGF’s WS-Naming Requirements EPR, EPI and Message

## GGF’s WS-Naming Requirements EPR Resolution Svcs (all)

## GGF’s WS-Naming Requirements EPR Resolution Svcs (from EPI)

## Identifier & Data Object Model

## caBIG-IRI Naming Convention

- Or a “random” suffix without semantics:
**bigid://1.2.2456/****MRTU4PDCC4HC6MQ4WSEZ2WZOARVRKPEM**
- Identifiers are opaque to applications - they shouldn’t care!!! (implementation choice based on deployment considerations)

## Identifier & Data-Service

## Identifier Consumer

## Identifier Consumer First Step

## Data Object Versioning...

- Complicated...
- Should it be reflected in the Identifier?
- NO
- Versioning should be part of Data Modeling
- “version” part of primary key
- Use cases determine how the versions are used
- Consumer needs interfaces to reflect usage
- Hide consumer from implementation

## Handle System Integration

- CNRI’s Handle System leveraged for the following:
- Global name prefix assignment(similar to dns-ip-name/ip-address registration)
- Global resolution infrastructure(how to find the resolution svcs)
- Identifier’s meta-data repository(context, identification, creation, ..., type, etc.)
- Integrated security model(trust fabric for Naming Authorities, ACL-based admin)
- The open source Handle server code is enhanced to accommodate pluggable co-location with DataSvc(caBIO has >200million data-objects regenerated every 2 weeks...)

## Identifier Services Framework: Next Steps

- High Level Architecture and Design Document (80%)
- Implementation Design Document - (in progress)
- Implementation of WS-Applications, Java APIs & Libraries (80%)
- Standardized identifier attribute extensions for data-object schemas (60%)
- Documentation & Tutorials (in progress)
- caBIO “volunteered” as first Identifier Producing Application (next week...)
- Excellent first application from a requirement perspective
- Experience will directly feedback in identifier svc development
- Data Owners and Curator applications will have easy to use APIs to associate standardized Identifiers with their data objects, and to enable global resolution of those Identifiers to the data-objects
- Client-Applications will have many options to use Identifiers to specify search queries, in result from queries, to retrieve associated data-objects, in Workflow directives, in papers/articles, in cross-references...