当我们所做的系统到一定的程度后，随着涉及的领域越来越宽泛，客户群也越来越多，我们的系统不得不需要第三方系统协作，或者将原有大系统分解成各个协作的小系统才能更好地完成任务。就好像KFC，收银员就负责客户端点餐、收银、找零钱、开发票是一个接待人员完成。而真正为您做餐的又分为比较复杂的分工，比如负责炸薯条的人、做汉堡的人、还有做盖饭的（KFC的盖饭，唉~~不说了）。而为这些做餐人员提供物料供给的又是另一些人。还有就是KFC外卖送，店员管理经理，是这些人撑起了一个KFC店面。每个人负责的分工都不一样，每个部门人员的分工都和别的部门人员的分工有交互才能完成客户整个的“吃饭”需求。当然了，KFC还提供了洗手间，里面有专门的保洁人员。

　　从实例看我们IT界吵了这么多年的SOA吧，说通俗了，他就是想让大型的软件系统像KFC这种提供服务类似，内部是各个小系统（相对于整个大系统来说的，有可能这里面每个小系统的规模都是十分大的），有可能内部员工来自于不同的国家，他们之间都使用统一的标准语言——英语进行交流。

　　Java的分布式系统一般都会遇到异构系统之间的交互，而且这些异构系统99.9%都是在不同物理位置的，需要网络进行通讯，互协作。也就是说当系统一大了，就要面临将群雄割据的系统逐一驯化，使之Java分布之系统为我辈所用。

　　问题

　　SOA让不同的系统之间使用标准的规范进行通讯，而每个系统暴露出来的功能，SOA称之为“服务”（Service），为客户服务得到位不到位，全看整个大系统运作流不流畅。系统之间没有SOA规范之前可能也进行过整合，协作，但是那个时候没有一个标准的规范限制住通讯的协议，那么造成一个现象就是：系统A与系统B进行因为不同语言，要进行协作使用的是WebService，而系统B与系统C因为大多数功能都是用Java实现的，他们之间可能出于同语言的原因，使用JMS进行通讯协作就够了。而过些时间又出来一个系统D，需要系统A与系统C同时与之协作才能完成一个复杂的业务逻辑了，怎么办？有可能同语言，采用更为古老的RMI，有可能直接写个socket通讯就OK。

　　基于以上的各种现象不同系统之间是采用不同的通讯技术或者说通讯规范的，那么就要求开发这个大系统的每个人都得需要了解其他很多种通讯规范，针对不同的协作系统的更改，进行相应的修改。这样就好比KFC的员工都说自己国家的语言，想和我交流吗，OK，先学学我们国家的语言咱们再交流。难道客户在柜台那边等着你们将员工内部所有的国语都学了个遍，交流顺畅了再要吃的？？客户说算了，还是“更多快乐，更多欢笑尽在麦当劳吧。要不早饿死了……”

　　所以说不同系统，尤其是异构的系统之间采用一个标准的协议进行规范，大家都按照这个标准规范来，以上各自为政的现象就能够得以解决。

　　SOA规范的要求

　　SOA的规范要达到的要求主要有以下几点：

• 　　统一的交互方式：这个目标就是解决上面异构系统之间的通讯问题
• 　　服务品质：也叫做QoS，包括了通讯的安全，可靠的访问。每个服务能支撑的访问量是有限的，流量控制，机器资源负载分配等等措施都是保证服务质量的。
• 　　依赖管理：大系统内部往往是小系统之间的耦合工作来完成，那么系统和系统间少不了就要产生耦合，或者说是依赖。那么SOA就需要有解系统间耦合的规定，不能让不同系统强制耦合在一起。
• 　　高性能，高可用：协作的系统，当然要性能过关，客户用着用着说，怎么报出Exception了，或者说“系统正在维护，请耐心等待”？就好像客户在KFC吃汉堡包吃出了……（不说了），那么这客户下次肯定不来KFC了，而且还向他的朋友说KFC怎么怎么样……

　　与其说SOA提出这些规范，不如说SOA提出了这些目标。实现了这些目标，那么至少说您的大系统、大软件是符合SOA规范的。

　　实现SOA规范的，可参考的标准有SCA和ESB。

　　SOA实现

　　首先大家不要误会，SCA和ESB不是2个对立的东东，他们不是麦当劳和肯德基，他们的关系类似于JPA规范和Hibernate实现之间的关系。ESB更像是个抽象的概念，而SCA是一个面向应用的编程和组装方式。使用SCA，开发人员基本不用考虑技术接口, 代码是纯业务逻辑。

　　SCA的发布服务：

　　SCA为了减少对现有系统的入侵，将现有系统的服务类抽象成接口，当然如果原先就是接口+实现类就更方便了。通过SCA配置默认将系统接口暴露成为SCA服务。至于具体的配置文件格式和相关实现类的配置Demo在此先暂时放一放。

　　SCA的调用服务：

　　调用服务的方式可以采用xml配置实现，借助Spring集成相关SCA框架的整合可以很方便的使用SCA服务完成自己的业务。这个有点类似Spring集成CXF，这个内容在此也先不介绍。

　　SCA支持的通信及其交互方式：

　　SCA规范规定通讯方式有3种方式，JMS、WebService、跟情况而定，如果应用处于同一JVM采用JMS，不同则采用WebService。当然了，通过扩展SCA也可以支持其他通讯方式。

　　对于系统间的依赖管理SCA并没做太多解决的规范，而调试跟踪也没提出具体规定性的方案。这当然取决于具体的SCA实现框架，或者借助其他开源工具，比如Maven、TestNG整合等等手工措施待见属于你们公司自己的基于SOA思想的SCA平台。

　　ESB和SCA不是竞争关系，ESB算是提出一些基于SOA理念的一些抽象概念，核心思想是基于消息中间件来实现系统之间的交互，将系统要通讯的消息动作放到一个统一的寻呼台（消息中间件），处理消息队列的时候，消息自身带着目的信息，之后就发送过去，完成业务逻辑，就相当于麦当劳有个中央总控，所有人都有一个随身携带着的寻呼机，客户来了买餐，前台打开寻呼机往中央寻呼台发送一条消息：“客人点餐，儿童套餐”，发送完毕后，中央寻呼机将此消息发给了后厨，后厨赶紧炸薯条，烤面胚，微波炉热牛肉。一切皆由消息总线进行任务分发。

　　其实ESB相当于承担了SOA提出的统一服务方式进行交互。

　　ESB框架需要具备以下功能：

• 　　标准通讯格式：方便系统间进行通讯
• 　　消息路由：根据消息的目的地将消息发送至消息目的地，整合分系统统一成完整大系统，这点BPEL做得十分到位。
• 　　支持消息的请求相应、订阅分发2种模式进行。
• 　　支持多网络协议：http、TCP、UDP
• 　　解决多种数据格式进行交换，数据间的请求数据格式有可能存在差异，消息总线要屏蔽这种差异。

　　综上所述，实现JMS规范的各种消息中间件，怎么看怎么和ESB所提出的规范相吻合。

　　总结

　　这次介绍了相应的分布式系统的特点和SOA提出来的目的，做大型企业分布式系统，利用SOA进行系统整合、一统的意义。当然这次仅仅是抽象概念的一些介绍。之后会有相关内容作为其SCA规范、ESB规范的具体代码实现的。

SOA已经不是什么新鲜词语了，笔者的感觉现在搞软件研发越来越像服务行业了，面对客户，面对客户的客户，我们只有提升自己的服务质量，才能营造更好的品牌效益。还是那句老话，任何技术的推动背后都是商业运作。