SaaS模式的CRM应用体系架构探讨

SaaS模式CRM架构较传统CRM软件的多层架构更复杂， SaaS模式下的CRM应用架构应该采用更高一级的架构。当前我们采用在传统方案的基础上加协作层，该层主要是为了在单实例多用户系统中能够控制用户定制，也就是说为客户提供了定制和配置应用，满足其特定需求的主要控制。此架构与采用服务导向型设计原理开发的其他应用很相似，进程服务给出了智能客户端或网络供应层可调用的界面，并能启动同步工作流程或长时间运行的事务处理，以调用其它业务服务，与各处的数据存储进行互动以读写业务数据。安全性服务负责控制最终用户和后台软件服务的存取（如图1所示）。

图1 SaaS模式CRM体系结构

1、元数据服务

元数据服务供应商为客户提供了定制和配置应用，是满足其特定需求的主要手段。通常，客户可在四大领域进行配置更改。

（1）用户界面风格：客户通常希望具有个性化界面的调整功能，以反映各自公司的品牌风格，因此SaaS应用通常都提供相关特性，以便客户能够更改图形、色彩、字体等相关内容。

（2）工作流程与业务规则：为了能广泛地向各种潜在客户提供服务，SaaS应用必须能够满足不同工作流程的需要。

（3）数据模型的扩展：对于许多数据驱动型SaaS应用而言，单个模型显然不能满足所有需要。可扩展的数据模型使客户能自由地让应用根据自身需要工作，而不必为了满足应用的要求而改变业务。

（4）存取控制：通常，客户负责创建每个最终用户各自的账户，并确定每个用户能够存取使用的资源和功能。通常通过安全策略跟踪每个用户的使用权限，客户可以对安全策略加以配置。与传统业务应用不同，SaaS应用更多情况下是由客户自身进行配置的。因此，设计配置界面非常重要。理想情况下，客户应能够通过向导或简易直观的屏幕指导进行应用配置，屏幕上应提供所有可用的选项，从而避免客户面临一大堆信息无从下手。

2、安全服务

在任何软件环境下，安全性都是至关重要的，SaaS的性质决定了安全性尤其重要，通常安全控制措施包括认证和授权两种方式，一般采用两种通用办法来解决认证问题：

（1）集中认证系统

对于集中认证系统而言，由供应商管理中央用户账户数据库，该数据库为所有应用用户提供服务。客户的管理员被授权在用户账户目录下创建、管理和删除用户账户。登录应用的用户需提供认证信息，根据中央目录下的信息加以确认，如果数据有效，就允许该用户访问。

这种方法所要求的认证基础设施相对简单，便于设计和实施，也不需要改变客户自身的用户基础没施。不过这种方法的主要缺点在于，集中认证系统很难实现单点登录（Single Sign on，即用户一次登录，就始终能访问企业网络）。没有单点登录功能，用户每次总会被提示输入应用登录信息，都要手动再次输入。

（2）非集中认证系统

在非集中认证系统中，客户采用可与其用户目录服务相连接的联合服务（Federation Service）。当用户尝试访问应用时，联合服务将对用户进行本地认证，并发布安全令牌，SaaS供应商的认证系统将接受安全令牌，并允许用户接入应用。

所选的认证系统不同，将导致架构的复杂性不同，也会导致最终用户应用体验的不同。因此在制定决策时，应根据商业模型的需要来确定应用、客户和最终用户的需要。授权通常通过“角色”的概念来管理，角色与公司中的特定岗位功能映射。每个角色都被赋予一项或多项许可，分配到某个角色的用户就能根据相应的业务规则来操作系统。

3、客户层

在该架构中客户端和浏览器均处于该层，主要作用是与客户进行交互，一般要求操作简单，使用方便，大多数是瘦客户端的形式，即采用Web浏览器加上纯Web页面来实现。对于特殊情况，如对实时性要求较高的音频数据、视频数据及实时控制数据等，可采用智能客户端的形式。

4、表示层

主要将客户层的请求转交到业务层，因此可以不考虑系统业务的实现细节，也往往作为登陆管理、会话管理等服务的网关。可以采用Sun公司的JSP/Servlet技术来实现。

5、协作层

这是SaaS模式中特有的，该层主要是为了在单实例多用户系统中能够控制用户定制，也就是说为客户提供了定制和配置应用，满足其特定需求。

6、控制层

主要作用是表示层与业务层，协作层与业务层交互的一个中间桥梁。也就是通过控制层来协调表示层与业务层、协作层与业务层之间的信息交互。

7、业务逻辑层

实现所有业务过程的实际处理逻辑，可以采用Sun公司的EJB中的会话Bean和消息驱动的Beans来实现。

总之，SaaS模式下的CRM软件系统应该是建立在多用户效率、高度可扩展性与元数据可配置性基础上的架构模型，并能够以极低的成本为现有的和潜在的客户提供出色的软件。