|Title:||University of Wisconsin: NSpace: Exploring Architectural Design Principles for a Next-Generation Institutional Repository|
|Abstract:||This presentation is intended to serve as a gentle but complete introduction to the architectural design elements of NSpace, a proof-of-concept prototype that explores an application infrastructure for a next-generation institutional repository. The NSpace architecture combines a number of emerging technologies to provide a flexible, modular framework for institutional repository development. The NSpace prototype uses a representational state transfer (REST) model for client/server communication, and employs a staged event-drive architecture (SEDA) manager for dynamic resource control and adaptive overload management; it also uses an inversion of control (IoC) container for runtime configuration of participating components. The NSpace framework cleanly separates client interfaces ("frontends") from server implementation details ("backend"). Frontends communicate with one or more backend servers using protocol-neutral transaction objects ("transactions"): clients embed transactions inside service request objects ("requests") that implement protocol details (i.e. the XML-over-HTTP "RESTful" communication model), and then execute the request. Request execution by the client replicates the transaction object to the backend server, which services the transaction and replicates the completed transaction object back to the client. All details of request execution are completely encapsulated by the service request object: from the client's point of view, the state of the transaction object simply changes across the call to the execution method. Although RESTful service requests are the current default implementation for NSpace, the architecture is designed to easily incorporate additional protocols (web services et al.) with a minimum of effort. The NSpace framework also modularizes the implementations of supporting code ("support modules") within the backend server. Individual modules are written as POJOs ("plain old Java objects") that include a transaction-handling method (one that receives a transaction object, performs processing activity on it, and returns it to the framework for further processing). Modules are assembled into sequences of cooperating instances ("chains"), which are then made remotely accessible through servicing endpoints ("services"). When the framework replicates a client transaction object, it is queued to the first module in the appropriate chain. Transaction "fall through" the chains, with each participating module given its turn to perform work; at the end of the chain, the completed transaction object is delivered back to the originating client. Again, the framework encapsulates and manages all runtime queueing and dequeuing operations as transactions move through the servicing chains: from the individual module's point of view, its processing method is simply invoked once per transaction passing through it. Most usefully, the transaction objects (represented as Java interfaces in code, or as DTDs in REST/XML representation) assume the role of the protocol-neutral, implementation-independent fundamental units of work done by the institutional repository. Development of frontend interfaces, client/server communication methods, and backend functionality implementations each become largely independent of each other, since each "end" of the code is insulated from changes by the common ground of the transaction objects. The NSpace project is also exploring the current state-of-the-art in coding techniques and practices: using Subversion as a source code repository; JUnit for unit testing; Maven for project management; and Eclipse for integrated code authoring.|
|Appears in Collections:||DSpace Federation 2nd User Group meeting|
Files in This Item:
|Additional resources for this item|
|retrieve citation metadata in EndNote format|
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.