【IT168 技术分析】随着2006年的结束，SOA从各大IT厂商推荐的概念变成了众多企业架构师需要实实在在勾勒的建设计划。并且建设的目的性一般都非常明确：“通过整合企业自身及合作方的各类技术资源，采用跨平台、跨产品的通用技术，把相关的相对分散的资源融合为一个逻辑的互联系统。”
从架构层次看，笔者倒是觉得ERP的概念似乎更有些生不逢时的感觉，不仅是各异的消息通信机制、开发组件技术，甚至于不同应用系统的业务功能也可以划在SOA整合的范围之内。抛开现有ERP产品包含的功能不谈，仅仅从“Enterprise Resource Planning”字面看SOA却是更好的“攒鸡毛凑掸子”的思路。也就是说，以往的ERP建设更类似以往的结构化设计，通过一个大而全的系统总体运筹企业，而SOA则是给整个企业IT资源计划提供了分步骤实施、迭代化设计的有力支持。
虽然建设的规模迥异，但是雷同的部分其实很多，如下：
（1）基本上统一采用XML Web Service作为Service封装技术。
（2）每个Web Service开发平台本身采用了非常先进的开发语言，即较新版本的.NET和Java开发语言。
（3）通过购买或者集成方式建立了强劲高效的企业服务总线（ESB， Enterprise Service Bus），并基于该总线完成了整个SOA交换环境的交易性、流程可配置性和访问控制等支撑服务。
（4）以Adapter方式接入每个Service Endpoint，并将Service Endpoint统一注册在服务注册器中。
（5）总体结构一般如下：
图：一般的SOA平台架构
不过在相关SOA的设计中由于XML Web Service本身处于HTPP + XML这种离线信息环境，因此很多以往在COM+、EJB很容易就能实现的控制能力被一定程度的弱化。因此为了达到与以往N-Tier企业分布式应用相同的IT控制能力，笔者认为需要从下面若干方面进行更深层次的技术突破。
做好SOA的纵深防御
这里借鉴以往系统安全上常用的“纵深防御”（In Depth Defense）来说，虽然企业服务总线上可以设计一个统一的认证和授权控制系统。但是就像SOAP调用可以很容易地穿越防火墙一样，非法的SOAP调用一样很容易不经过企业服务总线到达每个具体的Service Endpoint上。如果这里不设防，对于一个企业级的SOA应用而言可以说埋下了很多日后安全问题的伏笔。这里笔者建议在设计上，SOA环境本身也要贯彻“纵深”的防御方法。
图：SAO架构中需要实施“纵深防御”的元素
具体说明如下。
Service Registry：就像DNS等许多其他集中控制服务一样，Service Registry最起码要准备好应对如下两种方式的攻击：拒绝服务和毒化（就是篡改其配置内容，导致错误的Service路由或访问控制等）。
Service Endpoint：Service Endpoint作为与实际内部企业应用联结的纽带，除了可以实现信息交换外，访问控制也是设计上必须考虑的问题。而且为了适应企业安全规定和策略的修改，这部分Endpoint的访问控制或许还包括授权检查、流量控制也必须可以配置，并且这个配置不能依赖于Service Registry。当然，定义工作可以在Service Registry中进行，但是必须要保证其“推”到Service Endpoint后生效，否则就失去了“纵深防御”的意义。
Provider：Provider作为服务的提供者，如果设计不当，很容易被过度使用。
Adapter：Adapter本身一般仅仅和企业内部的Service交换信息，相对而言由于它是分散的，并且实际的处理能力一般瓶颈会限制在Service Registry和每个Service Endpoint后面的具体Service上，而Adapter自身一般也不管理实际的业务性信息，因此Adapter相对安全。只不过出于执行效率的考量，内部的Service可能运行于Load Balance上，但是Adapter却只是面向企业服务总线的单一组成，它的并发行会制约内部Service的服务效果，因此设计上除了考虑其功能实现外，并发情况下可能导致的可用性问题需要考虑。
外部服务访问接口：对于外部服务访问接口而言，则可以完全视为Web客户端。区分Internet、Intranet和内部代理远程Proxy访问、内部局域网用户访问等不同类型，通过在Web Server上定义访问规则来控制。由于现有JSP和ASP.NET平台均有不错的控制配置错误，考虑到系统整体的灵活性，建议这部分控制更多的由Web Server和Web 服务应用的配置部分完成。
