ERA Reference Architecture

1
ERA Reference Architecture

• Dyung Le
• 04/15/2009

2
Design Drivers

• Evolvability Extensibility
• Scalability Performance
• Configurability
• Ease of Use
• Maintainability, Operability Ease of Deployment
• Re-competability!

3
Design Approach

• Start with OAIS reference model
• Examine current Base and EOP systems and the
  current ERA RD
• Review business requirements from offices and
  IPT(s)
• Assume SOA paradigm
• Modular
• Distributable
• Swappable shareable
• Standard Interface is key
• Use open standards
• Standard internal and external interfaces -
  systems and users
• System platform to build, add new services and
  applications, enhance existing ones

4
Design Approach - continued

• Identify subsystems according to OAIS
• Loose coupling
• Autonomous
• Interactions
• Interface Objects
• Identify services in each subsystem
• ESB Pattern
• Layer Pattern
• To apply in the design of subsystems
• Use scenarios to validate the design

5
OAIS Reference model
OAIS
Preservation Planning
PRODUCER
CONSUMER
Descriptive Info
Descriptive Info
Data Management
queries
Access
result sets
Ingest
orders
SIP
Archival Storage
AIP
AIP
DIP
Administration
MANAGEMENT
6
ERA Reference Architecture
External Systems
Firewall
Firewall
Ingest
PRODUCER
Queries
Access
Transfer Processing
Ingest Processing
CONSUMER
Adapters (protocol binding And data Transformation
)
SIP
Result Sets
Access Working Storage
Search
Browse
TP Working Storage
Ingest Working Storage
Orders
Retrieve Asset
DIP
Browse, Search Asset Requests
Browse, Search Response
AIP
AIP Routing
Query Federation
AIP
ESB
AIP BO
AIP
AIP
AIP
Commands
Queries /Responses
Data Management
Description Management Application
Administration / Common Services
Preservation
Content Server
Preservation Planning
Content Server
Content Server
Business Object Management
ERA Storage
Storage Object Management
7
Content Server

• Content Server comprises Storage Object
  Management and ERA storage
• Serves up a set of content
• Expose a unified and simple interface
• Unified view of object and metadata via AIP
• Facilitates maintenance and synchronization
  between metadata and content
• Content server is more logical than physical
• May have multiple Content Servers mapped to a
  database and/or storage subsystem
• Similar to HCAP with respect to handling both
  storage and discovery

8
ACE and AIP
Item-level ACE
ACE ID ERA N-Part ID
IE Metadata
References to its Representations
Representation 1 Metadata
AIP Container AIP_N-part Identifier AIP
Components PDI Metadata File Filename N-Part
Identifier(for ACE).PDI.xml
Content Object(s) ERA-supplied Filename(s)
Metadata Management Component of ERA
Conent Object ID ERA-supplied Filename
Content Object Metadata
AIP

AIP ID ERA N-Part ID
Content Object
Preservation Description Information (PDI) Set
of unchanging metadata related to digital
object(s) in AIP
Filename ERA-supplied Filename
Filename N-Part Identifier(for ACE).PDI.xml
Archival Storage Component of ERA
9
CS and Varied Storage
10
Notion of Content

• How are Content Servers aligned?
• By Data collections (fed, legislative, census)
• By Data Type. Could help in specific storage and
  service offerings
• Document search vs database search
• By LoS. Could help in specific service offerings.
  
• Thumbnails in search results
• Full content search vs metadata search
• May need multi-dimensional alignment.
• Specific CS instances can be created as demand
  arises.

11
Search and Access Flow End-to-End
12
Search and Access Flow Single Site
13
Search and Access Flow Multi-Site
14
Layer Pattern
15
Business Object Management
16
Access
17
Search Access Components
18
Standardized Query
19
Preservation
20
Preservation