自去年加入新的公司到现在整一年了，职涯过程有些迂回，但总体实在曲折中攀升，首先谈谈我所参与公司的产品，该产品定位于SOA架构（SOA这玩意其实不是很新鲜的事物，大体上对其有一定的认知）。但是没有实操的经验，所以一路走来到现在，感觉是失败居多，同时也印证了古语：“失败是成功之母”，特别是最近的一段时间，我一直在反思这一年来SOA下如何设计与架构以及实施，多少有点自己的体会，记录下来，算是自己成长的步伐。
第一、业务的成熟度，SOA下最核心的一条就是 服务的可重用性。撇开技术不谈，首先服务发布是为了满足某一特定的业务实现，所以，业务的成熟度直接影响到SOA架构下服务的设计与可实施程度，选择SOA架构的背景是业务具有一定的成熟度，而且在相对的一段时间内，该业务是趋于稳定的，而不是变化的。另外一种情景就是作为产品设计者，对产品进行了高度的抽象，可以把底层公用的服务进行明确的描述说明，在这种模式下，SOA的引入才可能体现其复用的价值。否则，接口满天飞，每个业务的变更都需要对接口进行一次修正，而与之关联的服务都必须对此做出适应性的调整。其后果无法想象。
第二、渠道与业务服务剥离，首先这里定义的渠道是以总狭隘的渠道，是技术上的渠道，例如 http表单、WS服务、Restful、socket、ftp、MQ等，这些都是作为数据传输的技术实现，仅仅是一种数据通信的载体，在SOA模式下，一定要把渠道与服务做明确的切割，这里角度的讨论的粒度比较细致一些。服务是业务逻辑的实现，渠道仅仅是数据传输的通道，渠道可以多种，但是业务实现只有一种，把这种思维投影与传统的J2EE架构上，则表现为四层架构（web层、应用层、服务层、数据层），这种也是个人比较推崇的架构模式，传统的三层架构是一种被一些专家定义为是贫血模型，其实我也赞同这种观点。而这种投影在SOA架构则体现为（ web层、应用层、服务BPEL、服务提供层、数据层 ），唯一去别的一点就是 传统的四层架构 服务层的服务提供了一个整体的业务实现，而SOA下，可以把服务切割的更加细致，通过BPEL的组装实现一个完整的业务逻辑。三层架构下，实施SOA，对服务的粒度切割带来了更多的限制。
第三、服务消息的设计，记得以前有这样的一个面试笑话：问：什么是J2EE，答曰：增删改查 就是J2EE。无论是什么复杂的系统以及应用，都是围绕数据展开，这就带了一个新的话题：业务建模。在SOA模式下，为了实现其服务的灵活组装，必然要对服务之间的数据进行适配处理，如何符合接口之间消息设计没有一定的规则与逻辑，对于服务流程定制是一种能够噩梦，要分别针对不同的服务之间进行数据适配，显然这种是不可取的，特别是针对产品性的开发。一开始要内部业务流转的模型进行高度的抽象，从而定义出合理的接口消息协议。从而更好地实现服务的组装。

    第四、 事务控制，在SOA下，技术挑战之一就是事务的控制，这一点我也没有很好的答案，一种是基于JTA的跨库事务，一种是基于跨域的数据库事务，两者无法同时满足，这个也是一直困扰我的一点，无解。
第五、安全性考虑，安全在SOA下显得尤为重要，因为其分布式部署带来的一些问题，例如消息的完整性、消息的不可抵赖性、接口的容错性等这些都直接影响SOA运行的健壮性。

   第六、SOA下数据服务的提供，在SOA下，数据层是一个什么样的角色，如何定位数据层、以及数据层在SOA模式下提供什么方式的服务可以更好的满足系统，目前对于现在的我还是有所难度，例如SOA模式数据共享问题，元数据管理等等此类的问题。

     
   写完这些，都11点半了·~~ 收拾一下，买菜做饭。技术在重要也是为了生活。坚持不做技术男。哈哈~~~~~~