关于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才会得到质的发展。

评论

17 楼 fjlyxx 2008-12-10  

对了 ，我还发过一个帖子是关于 SOA平台中连接机制的讨论。有兴趣可以聊聊。

16 楼 fjlyxx 2008-12-10  

hongsoft 写道

fjlyxx 写道

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

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

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

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

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

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

我觉得你说的 需要一个  服务管理模块，这个模块要完成  路由转换、协议转换、数据转换 等功能。 这个范围太大了。

应该分多个管理应用。

比如 协议转换和路由转换可以由类似路由器的应用负责，这是一个，

还有同步需要一个。

数据转换 其实现在的只提供灵活的流程脚本（你可以理解为一段动态语言代码） 这个和ESB引擎有关了。比如上面的字典表问题就是这么解决的。

底层的连接也需要一个，服务的发布和管理需要一个。平台管理（包括监控和平台配置）需要一个。

关于路由转换 我不知道你的平台是怎么样一个架构，但是完全可以做到任何拓扑形状的结构，而且不需要静态寻址。

15 楼 hongsoft 2008-12-10  

呵呵，对于怎么样用SDO，我的理解是这样的：

1）SDO与业务无关。
2）SDO用来表示SCA的服务中的interface的operation的参数
3）参数为什么要用SDO表示？因为 SDO=XSD+跨平台

SDO首先只是一个XSD，跨平台的意思是 对于.net和java它是通用的（当然，MS并不喜欢它，这个是有原因的）。

bromon 反对SDO的理由，好像是说的  主数据管理。
的确，主数据管理 是个非常恶心的东西，在实际系统开发中根本不可行，也是IBM他们为了 卖产品搞出的概念。

也许SAP这样的产品中可以搞一个MDM，但是IBM这样的公司就不要搞这些了吧.....

14 楼 fjlyxx 2008-12-10  

其实这牵涉到一个很实际的问题，如果平台没有入侵到业务的话那么平台就赚不了什么钱。

13 楼 bromon 2008-12-10  

想了一下，我决定说个痛快。

长期忍受SDO之后，我坚定的认为应该废除这项规范在SOA中的作用，我甚至认为应该从SOA规范中去掉这东西。主要理由如下，很抱歉我没有系统的整理过：

长久以来business integration领域所做的事情，都是把业务还给用户，不再由系统集成商/应用提供商来主导企业应用的业务重建。这是多年来企业应用的教训，所以我们强烈的在SOA中鼓吹流程自定义，把ESB抬举到非常高的位置上，这一点我是认同的。

要支持足够粒度的流程自定义，就需要规范服务接口，这只是一方面的原因，技术方向上的原因。另一方面是业务方向上的原因：接口的规范、接口如何export、接口如何被管理，都是与业务无关的。所以它可以被规范化，这也是我最认同的：只有与业务无关的东西、或者关系很少且我们有足够的理由不理睬这些关联的东西，才应该被规范化。基于这一点认知，我认为SDO完全多余，因为软件体系是构建在一套领域模型的基础上的，领域模型是对业务的建模和重现，这是与业务完全融为一体的东西，不同的业务、不同的系统，会有完全不同的领域模型的对象图，我们不应该妄想在一个大一统的框架下来进行业务建模的工作，至少现在不行。但是非要搞出这么个东西，就会是一个非常抽象、非常普适以至于毫无用处的东西。就好像你去问，什么会带来成功，得到的只会是"坚持"、"不放弃"一类的big word.

抛弃SDO可以为service松绑，这对于integration有很大的积极意义。ESB中流转的数据模型应该是业务自定义的完整对象图，这套对象图是well formed的业务领域模型，这样做的好处非常大，第一可以强制的要求开发者给出良好的对象图，这会在很多地方带来好处，第二是自定义的对象模型更加轻量，更有意义，更容易自定义，更容易描述业务。坏处是这对于系统设计者有更高的能力要求，没有SDO那么抽象和普适。但是对于单个领域/应用而言，专用的、自定义的东西，往往比抽象的、通用的更有效率，因为它们有更加丰富的语义。所以我希望SDO不要像现在这么强势，它应该是可选的、没有更好选择时的选择。SDO是什么？不重要，SDO怎么实现的？不重要。重要的是在SOA版图的那个位置上，不应该有这个东西

吃饭了，不知道说清楚了没有....

12 楼 hongsoft 2008-12-10  

SDO基本对应到XML也就是 XSD，并不会强加太多的东西。

当然，我们也没有用它的changeSummary这样的东西，太重。

11 楼 bromon 2008-12-10  

hongsoft 写道

呵呵，我是 同意采用 SDO的。
SDO并不表示 重量级，我就是 SDO技术委员会的member，我们自己有SDO的实现。

我说的 轻量级ESB 是 认为不需要  EJB中的重量级那些特性（cluster....)

呵呵，瞻仰一下。不过我个人比较不喜欢SDO这东西，我更希望service之间传递的是一种更加外部化的资源，我不知道该怎样描述这个东西，reference? URI? 哈，这个问题我没完全想通。我希望SOA能够在接口规范上给予service更多的自主权，这样对于既有系统的集成更有意义

10 楼 hongsoft 2008-12-10  

呵呵，我是 同意采用 SDO的。
SDO并不表示 重量级，我就是 SDO技术委员会的member，我们自己有SDO的实现。

我说的 轻量级ESB 是 认为不需要  EJB中的重量级那些特性（cluster....)

9 楼 bromon 2008-12-10  

hongsoft 写道

fjlyxx 写道

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

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

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

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

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

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

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

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

8 楼 hongsoft 2008-12-10  

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

7 楼 hongsoft 2008-12-10  

fjlyxx 写道

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

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

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

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

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

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

6 楼 fjlyxx 2008-12-09  

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

5 楼 czx566 2008-12-09  

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

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

4 楼 fjlyxx 2008-12-09  

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

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

3 楼 hongsoft 2008-12-09  

fjlyxx 写道

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

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

2 楼 hongsoft 2008-12-09  

fjlyxx 写道

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

分析下这两种方式。

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

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

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

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

1 楼 hongsoft 2008-12-09  

写得有点道理。

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

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