210 likes | 242 Views
ERA Reference Architecture. Dyung Le 04/15/2009. Design Drivers. Evolvability & Extensibility Scalability & Performance Configurability Ease of Use Maintainability, Operability & Ease of Deployment “Re-competability”!. Design Approach. Start with OAIS reference model
E N D
ERA Reference Architecture Dyung Le 04/15/2009
Design Drivers • Evolvability & Extensibility • Scalability & Performance • Configurability • Ease of Use • Maintainability, Operability & Ease of Deployment • “Re-competability”!
DesignApproach • 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
DesignApproach - 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
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
ERA Reference Architecture External Systems Firewall Firewall Ingest PRODUCER Queries Access Transfer Processing Ingest Processing Adapters (protocol binding And data Transformation) CONSUMER 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 AIP Query Federation 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
Content Server Get AIP Search/Browse Put AIP Update AIP Delete AIP 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
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 Filename: ERA-supplied Filename Content Object Preservation Description Information (PDI) Set of unchanging metadata related to digital object(s) in AIP Archival Storage Component of ERA Filename: N-Part Identifier(for ACE).PDI.xml
Rich Content Search Database Search File Level Access CS CS CS ACEs ACEs ACEs Content Content Content Metadata Repository XML Server DB Archiving Server Archive Storage (file system) CS and Varied Storage
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.