1 / 15

Open SPP Architecture Notes

Open SPP Architecture Notes. 30 May 2011. Scope. Registry High level architecture concerns Repository and other elements not in scope. System Architecture. SPP. Registry To Registry. Registry. Registry. SPP. SPP. domain. Registry To Repository. Local Repository. Local

rowa
Télécharger la présentation

Open SPP Architecture Notes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open SPP Architecture Notes 30 May 2011

  2. Scope • Registry • High level architecture concerns • Repository and other elements not in scope

  3. System Architecture SPP Registry To Registry Registry Registry SPP SPP domain Registry To Repository Local Repository Local Repository SBE LUF ENUM SBE SBE Based on draft-ietf-drinks-spprov-07

  4. SPP to Registry SPPP as service and as batch, provision SED data Registry to Repository Batch updates of LUF data Updates partial, incremental and full Versioning Registry to Registry [propose] SPPP – share SED data SBE to Repository [ LUF ] ENUM System Interfaces

  5. Non-Functional Requirements • Consistency • Must provide all clients consistent query results or replication data for SED records • Integrity • SED records must never be corrupt • Persistence • SED records maintained for their lifetime in persistent storage. The registry is the authoritative source of SED data. • Availability • Can be supported through fail over mechanisms of the server infrastructure • Not high availability [ compared to repository]

  6. Non-Functional Requirements • Request Scalability • does not typically support a large number of simultaneous provisioning SPPs • Data Scalability • Must support a large number of SED records – especially PublicIdentifiers • [AI – to set benchmark] • Throughput • Draft mentioned near real-time • [AI – to set benchmark]

  7. Security Requirements • Authentication • WS Envelope protocols – such as SOAP WS-Security support digest and certificate • Authorization • Should define model [ RBAC] , granularity • Message Integrity • WS Envelope support • Batch File Integrity • More serious threat

  8. Non-Functional Requirements • Federation • Mechanism for multiple Registries to cooperate • Multiple registries to a repository ? • Extensibility • Not defined at this point

  9. Registry Interfaces & Components SED Replicator SPPP Batch LUF SPPP SED Replication Compiler SPPP Impl SPPP Batch LUF Simulator Registry To Repository Common RequestModel Defined By XSD In draft SPPP Command Processor SED Data Model Persistence

  10. Registry SPPP • SPPP Service interface • Request oriented • Decoupled from client [SPP] • Stateless • Ease of client development • SPPP Batch interface • File [ script] oriented • Support very large files [ especially PublicIdentifiers] • separate file transport [ ftp ? ] to known protocol • Scripting • Checkpointing / stateful

  11. Object Model Organization n Destination Group Route Group n 1 0 0 1 n n Public Identifier Route Record

  12. Separation of Concerns • Service Interface implementation • Service implementation uses container services • Web Service envelope implementation • Execution context, connections, resources, security • SPPP Command Processor • Interprets the commands as defined in XSD • SED Data Model • Manipulates persistentSED Objects • Uses persistence interface • Manages Sessions, transactions • Persistence • mapping layer to database and cache[ orm or any other underlying model ]

  13. Reference ImplementationOpenSPP • Server for SPPP Service Interface • SOAP Based • Java 6, JAX-WS stack • Requests defined in XSD • SPPP Impl • JAX WS Web Method • Dispatches request to SPPP Command Processor by reflection

  14. Initial Component Design Thoughts • SPPP Impl • JAX WS Web Method • SPPP commands defined by XSD in WSDL – received as strongly typed JAXB objects with hierarchy and polymorphism • Dispatches request to SPPP Command Processor by reflection • Handles context and WS protocol issues • Gets authentication result • Authorization enforcement

  15. Initial Component Design Thoughts • SPPP Command Processor • Stateless method • Validates the request • Invokes data model methods to implement command • SED Data Model • Interprets method to manipulate persistent entities and components • Logical queries interpreted as specific queries to persistence • Logical command methods implemented using Object lifecycle CRUD methods • For relational – may use Hibernate OR/M • Handles session and transaction management

More Related