关于SOA的几点思考

SOA(Service-Oriented Architecture，面向服务架构)开发领域谈论最多的一个词。
中国的SOA市场这几年发展的很不错，但也有很多是卖羊头挂狗肉的。打着SOA的旗号干起工作流的勾当(个人想法,且听我说完)。
我觉得SOA的一个很重要的目标是信息共享，解决数据孤岛的问题。那么离开了网络的SOA能算是一个真正意义上的SOA平台吗？所以我觉得说工作流就是SOA是错误的虽然SOA离不开流程。但是把SOA的思想应用到工作流的设计中我是很赞同的。（题外话）

中国现代化建设这么多年，信息孤岛到处可见，每个部门都抱着自己数据。这样造成了资源的浪费和生产力的下降。信息共享是发展的必然趋势。
我认为解决数据孤岛有两种途径：
1.数据集中。
2.组成分布式网络，并且网络中各个节点可以通过某种协议进行通信（SOA平台）。

分析下这两种方式。

数据集中是一个很理想化的解决方案，因为实际的环境，历史遗留问题和业务的需要很多数据是不可能做成集中式的。就算要这么做成本也太大了。

SOA平台对于现在的中国来说是一个可行的解决方案。相对于数据集中方式来说SOA具有灵活，不入侵，安全，管理方便和易扩展等特性。最重要的一点是它的成本小。

既然SOA能够解决信息孤岛的问题那么为什么在实际的应用中却频频受助呢？
我认为有以下几方面：
第一  平台规范，中国的SOA平台还不成熟，每个公司都有自己的规范。为了解决规范的问题适配器变得非常重要（没有规范带来的麻烦）。在缺少规范的情况下不同SOA平台都属于自己的王国，其它平台无法访问，这样就造成不同平台间的通信问题。更糟糕的是不同平台的信息孤岛访问接口都是按照各自平台标准编写的所以当两个SOA平台要整合的时候会非常的麻烦。
第二 信息孤岛，中国信息孤岛不少，但是愿意开放不多。客户都是希望从别人那里拿到数据而不希望自己的数据被别人看。正所谓巧妇难为无米之炊。
第三 信息孤岛历史数据问题，这也许是SOA平台的性能瓶颈所在。在实际环境中有相当一部分信息孤岛中的信息是没有规范的，甚至很多信息就是垃圾数据，表结构的不合理，没有索引等。这些问题都会让SOA平台的访问能力大幅度的下降。好吧在没有索引的情况下一句查询语句可能要执行几十秒。
第四 字典表带来的烦恼，假设A部门用1表示男性0表示女性，B部门用2表示男性3表示女性。碰见这种问题的时候就带来了一个疑问，B部门要怎么去识别A部门的字典内容呢？这个转换工作由谁来完成？SOA平台，A还是B？如果由平台定义一套标准A和B各自转换那么平台的标准得多大？好像有点不确实际。假如要B去转换那么B就得先知道A的映射，好像也不合适。在碰见这种情况的时候也许我们在发布A服务的时候就应该写一个适配进行转换，或者架设一个服务发布映射管理中心。换汤不换药其实还是定义了一个平台标准。不过现阶段这个问题还是好解决的因为B这端的请求接口还是由平台开发的要不然平台怎么长久赚钱呢？
第五 安全性问题，虽然SOA平台在安全性方面能做到很好但是在实际的环境中平台间传递的还是明文。如果传递密文那么对高访问量或者附带有流程的SOA平台来说是一个很大的性能损耗。
第六 网络的问题，其实网络不存在问题，问题存在于如何让SOA平台能够快速高效实时的传递大数据。好比大于2M的数据库如果用一个XML去传输那么就慢的可以了。分包，断点可以解决问题但是这并不能从根本上解决问题，SOA平台内部怎么减少传输量是一个课题。
第七 题外话，为什么要SOA平台呢？这个疑问确实很难回答。我把服务发布成一个WS接口这样就不信息共享了吗？还要你平台干嘛？没错是这样的。如果单纯是要数据的话这样一点问题也没有，因为一个WS接口不仅可以提供数据而且还能进行安全控制。那么如果我数据是需要从多个地方获取而且有一点逻辑呢？这个时候单纯的靠访问WS接口就不行了，然而SOA的流程可以帮你做到。所以我觉得SOA不是ETL工具，离开了ESB的SOA也不能算是正在意义上的SOA。而现在我国的SOA大多是没有ESB的，就是没有提供流程的。

所以我觉得，我国应该早定义出一个SOA的规范，只有在这个规范的指导下中国的SOA才会得到质的发展。

写得有点道理。

看你的图片以为是个女的，弄得我热血沸腾，还是换张吧：）哈哈

下面我具体分析一下你的贴子。

我非常同意两个途径的提法。但是SOA的特性，我并不认同。

1）数据集中是做不到的，“因为实际的环境，历史遗留问题和业务的需要很多数据是不可能做成集中式的。” 不是理想化的解决方案，是空想化的解决方案。
2）SOA之于 异构，就如 Agile 之于 需求的变化。Agile拥抱“需求的变化”，SOA拥抱“异构
”。SOA认为异构
是客观存在的，并且不可改变（这也是为什么我说 数据集中是空想的原因）。

字典表的问题，是服务管理的问题。这里的问题是需要一个平台+管理方法来解决的。（注意，这里的管理方法 也是SOA的一部分，非技术的那一部分）。
这个平台要提供 数据格式转换的功能。这个管理方法要 提一个 管理规范：别人 A依赖B的情况下，要用 B的为主；如果A与B没有关系，那么 不做改造也是可以的；如果A与B的依赖关系很复杂，就需要有个中间的 规范，规定大家都要这么做。 这里涉及到了SOA的路线图的概念，就是根据 用户的 特定情况和特定需求，来确定用户的信息系统架构处在什么层次，从而决定应该采用什么解决方案。
安全性问题 ，这个在BPEL的实现中有具体的解决办法。当然如果要说到性能和数据量的问题，这个的确是需要折中衡量的。

你提的SOA的这样的规范 是不存在的，以后也不会有，这也是 IT的秒处之所在。

OK 这里我提问你一个问题。
如果我需要多个应用协同工作时候，这个字典表的问题的问题又该如何解决呢？
比如，一个简单的流程，先去A获取一个人的信息，如果这个人是女人则去看看她的美容消费D，如果是男人则去看看他的C住房记录。这时候需要一个转换中间介质了吧？

做这个转换并不是技术问题的观点我很同意。SOA不能规范这也是事实，但是这确实影响了信息共享。

不同意楼主的没有ESB就没有SoA的定义！

当然一般情况下，有了SOA应该就有ESB~

没有ESB的SOA也许用ETL形容比较适合

这个问题非常好。这个问题其实是SOA概念提出的根本原因。

我认为的解决办法是 需要一个  服务管理模块，这个模块要完成  路由转换、协议转换、数据转换 等功能。

但是并不是ESB。（因为事情根本就不需要搞得如EJB那样复杂）

这个转换要加上 管理方法来协助实施。（请见我的今天的blog，有具体说到这个问题）

我认为 没有 服务管理功能 就不是SOA。
但是 与ESB并没有关系。

在一个良好的SOA application/solution中，这个不应该是个问题。service是SOA的最小服务粒度，它自身是高内聚的，数据字典是被封装的内部细节，与服务消费者没有任何关系。你提出的其实是统一对象模型的问题，现行的SOA方案中，大都会倡导一种使用统一对象模型的接口规范，相对成熟的是IBM的SDO(Standard Data Object)，与SCA也有点关系，就不多扯了。这样做的好处有很多，第一是便于服务的组装、接口转换、消息路由，第二是便于设计期、维护期的流程编排，包括状态机，规则引擎都能不错的支持。但也有它的坏处，因为这样的模型会封装业务数据类型(可以理解为数据流中跑的都是弱类型)，对于开发期的debug、维护期的错误定位有不太友好，其次是这样的接口模型稍显笨重，至少我个人不太喜欢。还有其他坏处，自行体会,

也有一些SOA方案倾向于更加轻量的处理方案，但是总体来说，没有SDO那么成熟，毕竟IBM的东西一般不是盖的...