#技术分享# SOA 我的一点愚见

       自去年加入新的公司到如今整一年了，职涯过程有些迂回，但整体实在曲折中攀升，首先谈谈我所参与公司的产品，该产品定位于SOA架构（SOA这玩意其实不是很新鲜的事物，大致上对其有必定的认知）。可是没有实操的经验，因此一路走来到如今，感受是失败居多，同时也印证了古语：“失败是成功之母”，特别是最近的一段时间，我一直在反思这一年来SOA下如何设计与架构以及实施，多少有点本身的体会，记录下来，算是本身成长的步伐。
  
     第1、业务的成熟度，SOA下最核心的一条就是 服务的可重用性。撇开技术不谈，首先服务发布是为了知足某一特定的业务实现，因此，业务的成熟度直接影响到SOA架构下服务的设计与可实施程度，选择SOA架构的背景是业务具备必定的成熟度，并且在相对的一段时间内，该业务是趋于稳定的，而不是变化的。另一种情景就是做为产品设计者，对产品进行了高度的抽象，能够把底层公用的服务进行明确的描述说明，在这种模式下，SOA的引入才可能体现其复用的价值。不然，接口满天飞，每一个业务的变动都须要对接口进行一次修正，而与之关联的服务都必须对此作出适应性的调整。其后果没法想象。
  
       第2、渠道与业务服务剥离，首先这里定义的渠道是以总狭隘的渠道，是技术上的渠道，例如 http表单、WS服务、Restful、socket、ftp、MQ等，这些都是做为数据传输的技术实现，仅仅是一种数据通讯的载体，在SOA模式下，必定要把渠道与服务作明确的切割，这里角度的讨论的粒度比较细致一些。服务是业务逻辑的实现，渠道仅仅是数据传输的通道，渠道能够多种，可是业务实现只有一种，把这种思惟投影与传统的J2EE架构上，则表现为四层架构（web层、应用层、服务层、数据层），这种也是我的比较推崇的架构模式，传统的三层架构是一种被一些专家定义为是贫血模型，其实我也赞同这种观点。而这种投影在SOA架构则体现为（ web层、应用层、服务BPEL、服务提供层、数据层 ），惟一去别的一点就是 传统的四层架构 服务层的服务提供了一个总体的业务实现，而SOA下，能够把服务切割的更加细致，经过BPEL的组装实现一个完整的业务逻辑。三层架构下，实施SOA，对服务的粒度切割带来了更多的限制。

     第3、服务消息的设计，记得之前有这样的一个面试笑话：问：什么是J2EE，答曰：增删改查 就是J2EE。不管是什么复杂的系统以及应用，都是围绕数据展开，这就带了一个新的话题：业务建模。在SOA模式下，为了实现其服务的灵活组装，必然要对服务之间的数据进行适配处理，如何符合接口之间消息设计没有必定的规则与逻辑，对于服务流程定制是一种可以噩梦，要分别针对不一样的服务之间进行数据适配，显然这种是不可取的，特别是针对产品性的开发。一开始要内部业务流转的模型进行高度的抽象，从而定义出合理的接口消息协议。从而更好地实现服务的组装。

    第4、 事务控制，在SOA下，技术挑战之一就是事务的控制，这一点我也没有很好的答案，一种是基于JTA的跨库事务，一种是基于跨域的数据库事务，二者没法同时知足，这个也是一直困扰个人一点，无解。
   第5、安全性考虑，安全在SOA下显得尤其重要，由于其分布式部署带来的一些问题，例如消息的完整性、消息的不可抵赖性、接口的容错性等这些都直接影响SOA运行的健壮性。    第6、SOA下数据服务的提供，在SOA下，数据层是一个什么样的角色，如何定位数据层、以及数据层在SOA模式下提供什么方式的服务能够更好的知足系统，目前对于如今的我仍是有所难度，例如SOA模式数据共享问题，元数据管理等等此类的问题。          写完这些，都11点半了·~~ 收拾一下，买菜作饭。技术在重要也是为了生活。坚持不作技术男。哈哈~~~~~~