白话SOA：面向服务+组件+架构
本文来源：阿朱=行业趋势+开发管理+架构
原文标题：媒体人和CIO能看懂的SOA
面向服务的组件架构。这就是字面直译。这恰恰是理解SOA最好的方法。
首先是1 组件。组件是什么？这个概念大家得知道。权威的OMG定义过。但不好理解，我给通俗一点，但决不个人演绎。接口标准化、契约化，功能模块化、封装化，可被组装组合重复使用。估计这个解释和大家心中想的差不多。（不过不像大家想的那样是属性、方法、事件）
2 面向服务。啥是面向服务？我们先说说现实中我们常见的服务。就拿最容易理解的餐饮服务员来说，点菜、上菜、换碟、拿餐巾纸、结账这是他提供的服务。咱们吃饭的时候从来不会注意他们是怎么提供这些服务的。这就是现实中的服务。而在软件中的服务，也是一样，有人提供了若干个服务，我们只想调用完成我们的事，而不想知道他们内部怎么做的。也就是说，暴露给我们的接口方法，就是我们要做的事。其他的，不要暴露给作为用户的我们。所以在SOA一般说服务说是粗粒度的。这就是粗粒度。很多人不明白粗粒度到底要多粗，大家可以看看taobao的开放平台和豆瓣的Open API，比如taobao.items.get，就是把取商品类目的函数，把参数传入，出来就是我们想要的结果。淘宝是怎么取到的，那是淘宝的事。
3 架构。要的是架构，横竖立体搭建的。而不是一盘散沙。要有点、线、面、层。如果组件是一个个的点，那么如何安置这些组件的生死、缓冲、并发、安全，如何让组件之间通讯，通讯的接口如何定义，通讯的协议是如何的，通讯的数据结构是怎样的，数据信息是如何保证不丢失的，数据信息是如何保证在各个组件之间流转到指定的组件？这就是架构。
我说了这么多，把SOA的关键都讲了。但这都是思想层面。首先你的思想对不对。如果你的设计是符合这个思想的，你就是SOA架构。
这样你就会说，过去我们做的EJB、COM+都是面向服务的组件啊，也有架构啊。我们十多年前就做了SOA了。
对，从设计思想来说，SOA一点都不新。
新的是从技术方面。
过去我们有EJB、COM+、CORBA三种主流的组件体系。然后我们要互操作，我们要跨互联网，这三种架构都有缺陷了。
于是让这个基于HTTP+XML本质的webservice来达到跨互联网互操作。
是的，有人理解webservice就等于SOA。
但是，组件与组件之间如何信息通讯？有人说我自己定义好接口，我自己定义好结构，一方传出，一方接收处理，就OK了。
但我要说的是异构系统的互操作，你刚才说的都是自己内部怎么做怎么做。
如果是异构系统异构应用去互操作，必须要遵守，你自己自定义一套规则和结构算什么，你老是自己玩，谁还和你玩？想大家一起玩，一起获利，就要有一套标准来遵守。这套标准，一般都是国际大巨头领导的协会组织制定的，只有他们有话语权。你自己制定一个算什么？
所以一整套规则都出来了。组件如何做组件具备什么特征才符合标准的组件容器管理，组件之间如何数据结构和消息通信才能互操作，这都是规则。这个规则就是架构。于是，在架构之下就有了企业服务总线来管理组件，有组件之间通信的数据结构（组件数据对象）和应用通信协议（这不是HTTP协议，也比SOAP这类应用协议还要高，是组件之间应用通信的协议）。
有了这些技术基础，但是大家搭建应用，还是很迷惑，于是，应用如何搭建可以符合组件特性，可以符合SOA数据特性，可以符合SOA流程特性。应该有个可以参考的完备规范让大家学习和借鉴。于是，应用架构设计规范又有出台。
我们总是在搭建应用软件的架构，这样的架构对不对，这样的架构完备不完备，我们过去只是靠经验来定义，现在我们终于有了一个规范。但这个规范参考可能太面向国外思路，所以不符合，但毕竟有我们思考的一方面。
在医疗行业，有HL7标准。是国外制定的。过去也很鄙夷不符合中国市场。但是仔细阅读后发现人家设计的规范与完备非常值得参考，用人家这套标准规范来设计，比自己用多年经验摸索设计的整齐的多。这才像架构，这才像系统。
不说了。争论谁是SOA，谁不是SOA并没有意义。因为每个开放标准定义的实际者都是国际巨头厂商，他们都会代表自己的利益而去争取一席之地。而我们自己还无法提出自己的标准，我们用的标准我们用的产品都是人家制定和开发好的，我们只是做之上的应用而已，所以人家为了自己利益而做的规范，这就是规范。IBM说IBM是SOA,微软说我才是SOA。对，这就是每个厂商的利益。你跟随谁的利益都OK。
但，我们做SOA不是为了跟随他们的利益。他们赚钱又不会给我们分一半。所以我们是要拿他们塞给我们的工具和技术来解决我们的问题。
我们要拿SOA解决什么问题？
如果我们要组件化（我们为什么要组件化，大家明白不？为什么要封装大家明白不，为什么要接口大家明白不？）
如果我们要跨互联网异构应用异构系统互操作，我们还希望这些应用都在一个盘中下这些不同的棋子，
那么，那么，我们需要SOA。