平台架构——体系结构
l 设计要点
Ø 应用与Web Service(简称WS)分离。
Ø 数据库与WS分离
Ø 应用集成
l 结构说明
Ø 简化的应用调用接口
Ø 重点模块说明
Ø 心血的结晶
l 接下来的文章
设计要点
应用与Web Service(简称WS)分离。
在“项目à产品à平台我的编程人生”中我提到了WS瘦身，以及瘦身所带来的各种好处（详细请看原文）。其实“为WS瘦身”只是一种技术形式，其折射的意义将更为深远，即应用与WS的分离。WS调用的透明化，可以使应用不知道WS的存在，这样我们可以方便地将WS服务升级为WCF服务。无疑这会大大降低升级成本！对WS调用的封装我称之为服务前端。
平台内各基础服务都是采用这种技术实现的，对于应用本身的WS服务，并不做要求，当然应用本身的WS也按照这种方式来实现的话，也会有相同的效果。
数据库与WS分离
在一般的小型应用系统中，数据库的连接信息会直接配置到WS中去。然而在一些企业级应用中，数据量会增加的很快，而且数据的时效性很强，于是最好的做法就是分库存储。另一种情况是同一数据库中存在相同结构的数据表，只是表的名字是不一样的。如：容器系统WS可以用作用户库、用户组，他们都在平台库里存放数据，其中用户组还在应用系统库中存放数据；另一个例子是授权系统WS，他可以将授权信息存储在平台、系统、多个资源库中。
数据库与WS分离的最大的好处在于WS服务可以重用！此技术在平台设计中被广泛采用。分离需要解决的一个问题,即如何将数据库或表信息传递给WS服务？Soap头可以帮助我们解决这个问题。
应用集成
这一部分是平台的一个辅助模块，是一个可选模块。主要有以下几方面的特点：
Ø 将业务逻辑与界面分离。
Ø 集中式界面管理，灵活的布局。
Ø 业务逻辑之间及界面与业务逻辑之间的数据交换。
目前此模块的设计只是第一阶段。其效果如同VS环境一般：界面可任意布局、界面之间的数据变化可被另一界面的数据驱动，可给用户带来很好的用户体验。现在还不支持插件，此功能计划在第二阶段进行实现。
该模块的核心思想是MVC，用于数据驱动。另外控制模块可以包括多个子控制模块，以使事件和数据可在多个模块之间进行传递。至于界面的任意布局借助的是第三方的DockPanel控件。
此模块在平台中是相对独立的，且只是对应用客户端有效，从架构角度来讲影响范围较小，固不做深入说明。如果时间允许或大家感觉非常有必要的话可在后面的文章中进行详细的说明。
结构说明
下面这张图是平台的整体结构图，除数据库层外，其余四层的左侧是平台实现的内容，右侧是应用实现的内容。
简化的应用调用接口
简化接口不光是方法的简化，还有就是调用的“入口点”的减少。对于应用来讲，对平台基础功能的调用是通过每个服务的“服务前端”进行调用的。我为每个基础服务只公开了一个类用于应用的调用，其类名形式为“XXXClient”。如应用在调用用户组、用户库或是用户功能本身都是以UserClient类做为入口的。这种方式可使平台使用起来更加的方便，也减少了学习曲线。
重点模块说明
Ø 中心：用于用户登录，如果成功，则获取中心服务发放的票据，并负责对票据进行验证方面的工作。票据的验证是较为复杂的一个设计，它结合了软件使用许可证来对票据的发放进行限制。票据主要用来保护WS调用，WS可自愿选择是否要进行票据的验证。为了安全起见，每个WS对接收的票据都是可被WS自身进行识别，即票据中包含要访问的WS信息，如果信息不匹配则验证失败，自身验证成功后，WS还要询问中心是否发放过该票据。
Ø 容器系统：先解释一下“容器”，用户组和用户来讲用户组是容器；稿件库与稿件来讲稿件库是容器，OK这是一个通用的容器可以用来存放任何东西！一般人多会有疑问，其实它只是一个WS和三个“模板”表。用户组表是模板表的一个实例，稿件库表也是模板表的一个实例，他们具有相同的结构，但每组表的名字是不一样的。在调用WS之前，我们会把业务相关的数据库表及连接信息告诉WS，这样WS便可以通用了！容器系统在这个平台里重用的机率是很高的，如用户库，用户组，稿件库，工作流库等。
Ø 数据库冗余：由于数据库与WS的分离，我们需要对数据库连接信息管理，同时还可以进行数据库的管理等附加的数据库操作，如同构数据库的创建，数据迁移等。所有这些操作可由数据库冗余系统来完成。该模块还有动态配置数据库的效果，同时为数据库服务的健壮提供了一定的支援。
Ø WS地址冗余：在一个大型的应用中，会有众多的WS，客户端的地址配置工作不是一件让人喜欢的事情，于是提供了此模块，这对大量客户端的部署是非常有意义的。它包括服务地址的注册、管理、查询。其中注册和管理需要平台级权限才可以进行。
Ø WS辅助：该模块是为了简化WS代理的创建工作而设计的。如加工WS的数据库连接信息、票据信息以生成相应的Soap头，并自动将这些Soap头信息附加到当前WS上去。该辅助对象同时还提供向中心索取当前WS服务地址的方法。
这里只对体系结构做一个简单的说明，你会发现没有讲到用户和授权，因为这两个模块相对于其它模块来讲是一种更为具体的应用，当然也属于平台的基础功能模块，可在后面的文章中单独讲这两个东西。
心血的结晶
这些模块有些比较独立，有些则相互依赖。个人感觉层次还算清晰，从有想法要做这样的东西到现在这张图的成形，我在曲折的道路上花了一年多的时间，然而没有12年的从业经验更是不可能做出这样的东西来，每一个模块里面的细节又有谁能体会到呢？如通用数据缓存技术，WS辅助里的泛型及反射的应用等等，每一个模块都是经过无数次的迭代才定型的。
接下来的文章
要讲的东西很多，我有些担心，什么时候可以将全部的内容写完，或许永远写不完。平台是一个整体性的东西，但又是被分化和独立的多个模块组成。它的内容是可扩展和可替换的。所以没有真正的结束。而文章是可以结束的！
当然我不会扫大家的兴，我只是想一个人的力量真的很小！在接下来的日子里，我还会为大家提供一些具体模块的设计信息，全部都写下来是不太可能的事，挑一些写吧。还请大家见谅！
