企业SOA：“纵深防御”与“Endpoint”实施

    完成更“好”的Service Endpoint

    这里一个“好”字同时包括了多层的意思：“更好的”扩展性、“更好的”响应效率、还有上文提到的“更好的”访问控制等。笔者之所以在这里强调Service Endpoint，主要和所见的一些企业建设过程有关，很多企业通过.NET和Java提供的互操作特性，在没有对整体Endpoint做出比较慎重的规划后，很快地把许多以前的组件环境包装为XML Web Service版的Web组件——相对而言非常大的精力放在企业服务总线上。虽然这会在企业SOA的初期快速地取得成效，并且完成一个适于企业Then and There的SOA环境，但说到底企业SOA毕竟不是为了技术而技术，更多的是为了后续的业务。这里每个后续的业务就是由不断加入的Service Endpoint提供的，如果这一层设计上有缺陷或者缺乏扩展的话，以后修改的代价就会很大。 

    在技术实现上，Endpoint一般会采用WSDL的方式描述如下五类元素： 

    （1）Types：包括可由Web Server守法的消息Schema定义，一般是XSD（XML Schema）。 

    （2）Message：主要是充当消息和消息定义之间的关联的交叉引用。 

    （3）PortType：定义了XML Web Service可以对外公开的Service Interface。 

    （4）Binding：将PortType与具体的协议进行关联。 

    （5）Service：定义了XML Web Service对外服务的一组Port的集合。 

    虽然XML信息本身是Schema比较容易扩展的，但是每个企业SOA特定版本中Endpoint所能说明的，或者是企业服务总线所能理解的内容，如果采取编码方式完成还是非常有限的，设计上需要配置一个非常灵活的结构。 

    当然，对于控制类处理，相信各位架构师可以采用Intercepting Filter模式完成。如下图：

图：Intercepting Filter模式图

    具体说明如下： 

    （1）每个Web Service调用时，都需要把其调用内容通过Filter Chain进行一组筛选。 

    （2）每个Filter通过执行特定的检查（Header / Body）来反馈某一个控制内容是否通过验证。而且Filter Chain中的每个Filter都是可以被插入的，大家共同实现统一的IFilter接口，因此整个控制层是个可配置、可灵活适应的。 

    （3）不仅仅对于Web的Pre Process，包括多Post Process也都可以采用类似的方式完成。 

    例如：为了避免外部直接访问到具体的URL的Service，可以用Filter完成调用消息的特定路由；假设企业统一的策略是要对所有的Internet传输数据采用基于RC4算法Key SHA1处理的对称保密处理，那么可以对接收的Request通过一个Filter做解密，而在Request数据业务部分完成后，通过另一个Filter对其进行Post Process的加密处理。 

    不过，上面完成的是技术层面的扩展考虑，对于业务本身的易变性还需有必要的扩展准备。例如：一个Web出版物发放系统，其中有个功能叫“给出版物的序言增加出版社的签名”，以此保证用户在网上书店购买的时候可以阅读到正式的序言，而不是被别人篡改过的序言说明。

    以往序言都是通过文本方式保存在Perface的表里面的很多NVarchar字段中，后来有可能被保存在PerfaceOnline表的一个XML数据格式的字段中，但是从贴近业务的技术表述上来看，WSDL关于这个方法其实都是“取得序言数据，并对其编码后的信息由出版社的CA进行签名”。对于建设初期的SOA环境而言，“取得序言数据”这个操作可能在某个Service内部完成。但对于更加集中管理后的企业SOA环境而言，Data Service Provider一般会从具体的服务中抽象出来，也就是从下面的应用数据自治模式转换为集中数据模式。

图：应用数据自治模式

图：集中数据模式

    在集中模式下，可以通过让Service Endpoint“读懂”一些业务化的操作来更加灵活地适应业务要求。为了建立起业务语言和技术处理的关联，这里需要引入表达式解析引擎，并在这个引擎中增加可以解析某些业务化函数的Function Parser。这样，新的执行过程变就为：

图：增加了表达式解析引擎后的执行过程

    具体说明说明：

 （1）通过Express Parser的加入，保证了业务Service可以更为宏观地完成很多业务处理，而更好地隔离了具体业务实现部分。例如：上例可以写成Sign(GetPerfaceData(ID))。这样，即便再次出现数据迁移和数据存储方式的修改，也可以保证Service Endpoint部分的稳定，唯一需要做的就是修改一个Function Parser的函数解析部分。

 （2）每个Function的Parser可以重用。例如：业务上又需要确保序言和封面都是可靠的，那么仅需要组合GetPerfaceData()和GetCoverData()两个Function Parser，新的表达式也就变为Sign(GetPerfaceData() + GetCoverData())就行了。

    总而言之，增加了可以“读懂”业务化语言的Service Endpoint，也就为您的企业SOA后续的发展预留出了更加“聪明”的服务切入点。

    后记 

    文中笔者仅仅根据自身经验，对于企业SOA环境建设中几个技术设计考虑的要点进行了讨论，随着类似工作的继续进行，笔者会将更多的设计要点拿出来与各位架构师探讨。