系统框架分析DSpace的系统框架由存储层、业务逻辑层和应用层组成（如示）。存储层是系统的底层，主要进行信息对象的存储，它包括内容对象（也就是位流数据）和元数据。DSpace通过文件系统的方式实现了任意内容对象的存储，元数据的存储则通过关系数据库PostgreSQL（或其他关系数据库）来实现，系统调用JDBC完成存储。业务逻辑层是中间层，它包括了系统的用户权限管理、认证、工作流管理、标识符（handle）管理、检索、浏览等。应用层是DSpace与外界的交流层，除了已有的Web用户服务、OAI元数据提供服务、批量摄取服务外，用户可以建立接口扩展更多的应用，比如CNRIHandle插件服务和联邦服务等。
总之，DSpace的模块化程度高，具备很强的扩展性。它不仅根据服务对象的不同将仓储系统分为三层，而且在每一层的应用上各种具体操作都相对独立，并针对不同的应用创建不同的功能模块。在模块耦合方面，DSpace基本采用应用接口进行通信，包括层与层之间的数据通信和层内的数据通信。这种应用接口API的使用非常便于系统的应用服务扩展。
数据模型分析DSpace数据模型DSpace将它所拥有的数字资源从总体上划分为若干个Community（组织），通常Commu-nity指院系、部门等，它容纳该组织中的所有相关资源。Col-lection（馆藏集合）是Community下逻辑相关的资源集合，如某个课题组。Collection由Item（信息对象）构成，一个Item就包含了一个存档文件的所有存档元素，存档元素包括元数据集和若干个Bundle（数据包），尤其多个Bundle的方式可用于表现复杂的知识对象，如包含图片的HTML对象。每个Bundle中还包含了Bitstream（位流数据）和Bitstream的存储格式。
DSpace的OAIS功能映射解析以上述内容为基础，笔者对DSpace进行了更为深入的OAIS功能分解（如所示）。其中，①代表DSpace的摄取过程分解；②是保存计划分解；③为管理过程分解；④表示存档过程分解；⑤表示数据管理分解；⑥指访问过程分解。
分解结果表明，DSpace基本涵盖了OAIS取、存档、访问、数据管理、保存计划和管理等6大功能，并且在这6大功能中都有较为具体的解决方案，较好地拟合了OAIS的功能模型。但也必须指出，DSpace还存在许多不足，尤其是长期保存特征不够鲜明。
DSpace本地化过程中的主要问题及解决思路尽管DSpace有很多优点，但在本地化过程中，还是有很多问题值得我们关注。下面是笔者在DSpace的本地化过程中遇到的一些主要问题及其解决思路。
中文支持问题DSpace本地化的首要问题是中文的支持，DSpace1.3版本已经开展了一些国际化（I18N）服务的尝试，例如，采用Unicode国际化字符集在一定程度上解决了信息交换的中文字符的解析问题；采用标签文件（Messages.properties）支持多语言模式增强本地语言转换的便利性。通过实例测试和源码分析，笔者认为中文支持主要存在以下三方面的问题：①信息交换的中文支持；②Web界面的中文支持；③索引中文支持。
信息交换的中文支持信息交换是要保证信息的正确传递和解析，由于长久以来国际上形成了SBCS（单字节字符集）和DBCS（双字节字符集）两大类的字符编码系统，例如，ISO8859－1就是SBCS，GB2312就是DBCS，那么在同一系统中直接使用两种完全不同的编码规则非常容易引发信息交换的紊乱。若在DSpace中正确实现信息交换，首先必须解决字符集的问题。DSpace已经将Unicode作为它的底层处理字符集，Unicode是一种能够包含几乎所有字形的字符集，解决了诸如中文的亚洲语系的字符显示问题。因此，对于当前系统的本地化建设而言，亟待解决的问题是保证信息交换过程中的页面信息提交、Servlet响应或数据库提交等均应以UTF－8作为其编码方式。