SAAS相关技术要点整理.docVIP

SAAS相关技术要点整理 这篇文章本来是我们开发组内部用的一个小文档。因为我们公司以前没有做SAAS的经验，就成立了一个小组做一做这方面的技术前探，我是成员之一。这篇文档想从宏观的层面把开发一个SAAS应用所要用到的技术点稍微梳理一下，便于指导后面的技术前探工作。之所以发在这里，是因为自己相关的研发经验太缺乏，可能有些技术盲点是自己根本没能考虑到的，希望园子里的各位大牛多多指导。 一.聚焦“三头怪” ? 在MS的官方文档中，把构建一个足够成熟的SAAS（MS简单列出了SAAS应用的4级成熟度）所面临的3个主要挑战：可配置性，可扩展性，多用户存储结构设计称为“three headed monster”。在MS给出的两个SAAS的demo(分别为LitwareHR和Crab)中，着重解决的也是这三个问题。所以，我们在进行技术前探的时候，也要扣准这三条主线。 1.概念? SAAS是一个典型的“单实例多处应用”的软件类型，这就要求实例本身在不同的应用环境下有很强的配置能力。具体说来，需要对以下4个方面提供配置能力：? （1）程序的外观。? （2）工作流程与业务规则。? （3）数据模型。? （4）用户及最终用户的存取权限。? 这种自定义的能力应该在易配置性和配置能力两个方面做好权衡，最优的结果当然是通过最方便的配置手段来实现最复杂的自定义功能，但这并不容易做到，所以有可能我们会需要为一些比较高级的用户提供基于已有系统的二次开发能力（使用脚本等）。下面我们就具体来谈一下关于可配置性的各个方面。 2.配置的实现基础：元数据（MetaData）? 系统通过配置数据展现不同的外观和行为，那么对整个系统来说，配置数据就是系统中的元数据。笔者自己也没有特别研究过元数据，仅仅是开发中用过一些xml文件或者数据库中的特定表来保存一些配置信息，但对于一个成熟的SAAS应用，这种简单的配置方式可能是不够的。如何设计出结构灵活、功能强大、兼容性好的元数据结构，如何在代码中提供最有效率的元数据服务（Metadata Service），如何定义元数据的元数据（Metadata of metadata），如何保证在元数据结构发生变化的时候不影响程序的运行，这一切都需要我们在对元数据本身的语义特性和可能的技术支持手段进行过调研之后才能得出。另外，笔者在写这篇文章的时候，很偶然在网上找到了几幅关于元数据服务层设计的图片，很有意思：上面这幅图的上半部分给出了SAAS参考体系结构的一个概念模型，下半部分则给出了对应于体系结构的每一部分，现有的可能采取的技术手段。我们注意到，元数据服务和元数据数据结构定义是里面唯一的盲区。?? 下面这个图是Matias Woloski给出的对各主要配置模块（界面、业务规则、多用户数据结构、访问控制）提供的元数据服务的可能解决方案，也许可以做为我们进一步深入的一个线索。3.配置的需求基础：业务共性提取与业务个性分析? 为什么是所有tenant共享一套代码？因为所有这些用户在软件需求上有共同的需要，在业务流程上有很多共通的地方，他们所有的应用都是在一个比较确定的业务领域（Business Domain）内展开的。我们需要把这个业务领域内的业务需求梳理清楚，然后提供我们的软件为这个业务领域服务。既然他们都属于一个业务领域，那么我们提供一套可以运行的软件就行了，为什么还要提供那么强的配置能力呢？因为同属于一个业务领域内的客户，他们在业务规则的细节上其实有很多不同，业务流完全相同的两个企业其实是不存在的。另外，每一个企业都在不停的发展变化，业务结构也都在不断的调整、重整、升级过程中，我们的软件应该可以在一定的弹性范围内，支持企业的这种升级。? 所以，研究我们的SAAS软件所要解决的业务领域特点，找出这个领域目前在横向范围内的企业业务间的差异性，以及在可以预见的将来的业务升级要求，其实是实现SAAS软件最开始的、也是最难的一步。但这一步骤本身和技术的关系可能并没有那么大，所涉及的最多也能也就是包含UML在内的众多领域建模技术。这一部分应该属于SAAS研究中业务和技术结合、同时业务占据的比重更大的一部分内容。 4.配置主要内容1：程序外观的配置? 外观的配置其实包括的内容很多，但比较核心内容笔者认为是界面元素的多粒度模块化，只有实现了这一点，才有可能让用户在多个粒度级别上去定义自己想显示什么、以什么样的界面风格去显示。这一点上也一直是笔者认为.Net比较有优势的地方，因为MS的产品一直在构件化上面表现不俗。仅就A2.0中，已经有Custom Control,User Control,Web Parts,Theme, Skin, MasterPage等成熟界面技术可以使用；在.Net3.0的WPF(现已更名为Sil