CXF学习（一）---SOA

       目前在一家互联网公司实习，由于本科期间接触.net比较多，就被安排到了.net开发队伍之中，但由于专业方向选择的是JAVA，对java还是保持着那种不变的热诚。到公司，知道这里用的是WCF，用起来感觉挺不错的，就想着JAVA有是什么类似的技术，了解到公司JAVA方向用的是CXF，于是便有了学习CXF的想法。

       开始了解CXF的一些理论性的知识，结合实习期间对WCF的了解，了解到这是基于我们上课学习的SOA（面向服务的体系结构）体系结构（虽然上课没认真学，但还是有点映像的），还是来复习一下SOA吧。

       SOA（service-oriented architecture）面向服务的体系结构，这也没有一个标准的定义，自己理解就好了。我的理解就是它是一种松散耦合、粗粒度的服务结构。首先什么是服务，SOA关键点就在于服务，W3C是这样定义服务的：“服务提供者完成一组工作，为服务使用者交付所需的最终结果，最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态发生变化，或者双方都发生变化”。这样的定义可能会比较抽象，举个例子：像我们公司开发的东西，在一个业务规则判断的应用程序里面，尽管需要大量的数据库数据，也不会出现数据库操作，获取数据完全由一个数据基础服务去完成，这个服务在正式运营的时候一直是运行的，只要那个应用程序有需要数据请求，都会向这个服务提出请求，基础数据服务在根据请求返回相应数据。这样的情况会有很多，现在企业级开发很多都会采用SOA的体系结构，这样保证之前开发的结果也能够正常使用，有新的需求可以新开发一个服务而不停止原来的服务。

      关于SOA的特性呢，首先是松散耦合，在SOA中我们通过服务提供者和使用者商量好契约（接口），大家都按照契约办事，服务者只提供服务结果，使用者不用知道这结果怎来的。就如我们去餐厅吃东西，你去了以后点好餐，过一会服务员就给你端东西来了，这样你看不到食物产生的过程，只是你要符合契约，提的要求是点餐而不是其他不符合契约的需求。在SOA中大量的服务通过这样的方式在运行。服务使用者与服务提供者的关系就只有那一个请求和结果，这就降低了模块间的耦合度。

     在SOA中一个服务往往提供一系列的方法，完成一系列相关工作，一个服务往往在接口中暴露出当前服务所能够提供的所有方法，比如我们要写一个用户服务，什么登录、注册、信息修改啊之类的以及一大堆与用户基本信息相关的我都可以用一个用户服务来完成，让这个服务暴露多个方法。这就是SOA的另一特性粗粒度。

     体现SOA的系统结构的并不是这两个特性，而是我们对服务的管理，我们可以开发很多的服务，但服务请求者面对这么多的服务可能就会有些崩溃了，正如我们的周围有着许多的餐厅，他们提供者各种各样的服务。如果说我要随时找吃饭的地方，怎么办，在没有什么信息查询的时候我就必须的事先记得所有餐厅的地址，这才便于让我找得到这家餐厅，人活的久了去过的餐厅也多，如果都要记得话，这的浪费多少脑细胞啊，还好我们现在有各种地图。我们必须的提供一个管理服务，让服务请求者不用太关心某个服务在哪个地址，哪个端口，这更像我们现在所用的外卖，我们只用知道这个管理服务在哪，然后去请求这个服务，让他告诉我我要的服务在哪儿，或者让她帮我去请求我所需要的服务，这样我们不用去记地址，这在SOA里面，我们把它叫做服务总线，在我们公司，我们叫做服务路由。

     有了服务总线，我们就可以长期的开发新的服务，就能和以前的服务一样运行使用，服务间的依赖性尽可能的降到最小，服务总线在我看来可以是一个组件，也可以是一个服务。我所理解的组件就是能够调用来找到某个服务的地址，工作的主体是调用者，服务可以帮我们去操作，主体是服务。我更倾向于用服务吧，觉得这可以动态的去协调我们的请求，当然组件里面的规则算法够好的话，组件也是不错的诶。。。。

    可能说到这里也没说清楚SOA与CXF、WCF有什么联系，SOA的一种最为广泛的实现方式就是WebService，WebService 几乎成为了SOA 的一个标准了，而CXF是有Apache搞的一套WebService，WCF是微软搞的一套，这里面的点点滴滴就不先深究了，还是先把技术搞明白再说吧！ 好了，从现在开始，就开启CXF的学习之路吧。。。。