SOA Patterns simple impression 

《SOA Patterns》这本书出了有几个月了，可惜一直没找到下载。最近在dzone.com 上找到一份refcardz ，得以管中窥豹。本文简单的介绍下这本书都写了什么，以及在我眼中哪些章节更值得期待。

–本文以下内容按照SOA Patterns的内容排列–

Basic Service Patterns – 基本服务模式

Aggregator – 聚合器
因为SOA系统只能保证消息送达，而不能保证按顺序送达，所以应该把几个有顺序要求的消息聚合在一起发送。这样避免了额外考虑消息状态和顺序的开销，更有利于异步处理消息。

Service Bus – 服务总线
这个不用说了，现在流行概念ESB。这里主要指ESB消息路由的功能。

Dynamic Routing – 动态路由
可配置、非过滤的消息路由。过滤方式的路由会导致endpoint接收所有的消息，而这个动态路由则位于过滤器之前，而起它的过滤规则可配置，甚至是由endpoint一侧的应用配置。

Event-Driven Consumer – 事件驱动的消费者
阻塞的监听或轮询方式浪费资源。通过基于总线或者特定于应用的callback机制可以更高效的处理消息。

Filter – 过滤器
系统间独立于平台的一种消息处理方式，并且不引入新的系统依赖或者不必要的耦合性。注意过滤器的对外接口要一致，以便灵活组合。

Router － 路由器
[...]

滥用SOA 

最近一年多满耳朵都是SOA的宣传，几个QQ群里也都在一直忽悠概念，大家都想往SOA上靠。这让我想起有人说到股市的一句话－－当大家都疯狂的时候，离崩溃就不远了。就我所能接触到的范围内的情况，种种迹象显示SOA已经开始泛滥了。

看见这篇B文的同学可以对比下自己周围的项目情况：
1、是不是有人言必及SOA。
2、是不是就连内部系统也要往SOA上靠。
3、没有实际的需求，假想未来两三年的应用场景，然后硬加上SOA。
4、攀比，跟风。大家都SOA了，我们也快SOA吧。
5、听了厂商忽悠就也非要把系统带个SOA，仿佛不这样就不好意思出去见人一样。

特别说明下列情况不算滥用：
1、SOA培训班，忽悠的就是SOA这个概念。
2、挂上SOA名词后合同额涨三成，经济危机现金为王。

有天在群里看见这么个消息：”现在有项目，找人合作，地点最好在深圳。要求：windows系统下，在驱动程序（C++编写而成）中，调用web service更新驱动程序，时间2周。”。这个应用场景具体的特点我不清楚，但我实在是想破头也不明白为什么驱动程序的更新都要用web service，难得就因为这年头流行这个概念吗？

还有个兄弟，他们已经是专门拿SOA做卖点来忽悠客户了，而且据说效果还不错。根据上面“不滥用”的特例，兄弟所在的公司没有滥用SOA，但是合同甲方有严重滥用嫌疑。

另外一个兄弟，天天在群里忽悠他们的SOA（工程）硕士培训班，而且号称企业与高校合办。再根据“不滥用”特例，这兄弟没有滥用SOA，但是那些被忽悠去的同学们可千万先想好了啊。

那么问题来了，如何避免滥用？首先要肯定SOA确实有它的优势，否则它也不会流行起来。肯定了这点，然后我们再来看，哪些是SOA适合的场景，只有在适合的地方才能发挥出它最大的潜力。

在强调松散耦合、多应用交互、快速变更业务流程、分散数据集中显示等等的场景中，SOA是一种很好的架构风格。松散耦合，这个不用说了，通过XML（其他的方式也是可行的，XML显然最通用）定义服务接口，有了这个中间层，服务之间的耦合性可以降低很多。多应用交互，不同的应用通过暴露服务来实现应用之间的交互，甚至这些服务可以组织成新的有价值的应用。把已有应用的服务重新组织排列成新应用有几点好处，一是快速，因为单个服务都是现成的；二是灵活，服务之间松散耦合，可以灵活改变组织方式；三是省钱，现成的拿来就用了，实在没有再开发任务量也不会太大。分散数据集中显示，XML不作为应用接口，而作为数据呈现接口，可以统一处理对比分散但存在相关性的数据，而且取得数据的方式与提供数据的应用间的耦合性被降低了。

但是如果是一个应用的内部作为分层，SOA就不适合了。首先这种内部分层几乎不可能暴露给外部，因为它们的粒度大部分都不足以提供一个有意义的功能。其次，SOA需要某种形式的XML文档来作为service的表现形式，而一旦采用XML就注定了它的性能是个硬伤，而作为内部系统来说，这种硬伤是不可能绕过去的。还有就是这种为了SOA而分层必然会加大层与层之间的工作量，结果却是没有带来任何收益，费力不讨好。

贴近底层系统的应用，使用SOA也是不合适的。这种情况下不同应用分层之间存在耦合的情况比较少，即使存在耦合其耦合性也比较强，而且一般都有更高效的接口或通道来作为耦合机制。对这类应用我实在是不太了解，大概会说的很片面。不过就我在上学时期做单片机应用的经验来看，确实很难想象在底层的应用中引入SOA会是什么情况。当然SOA的思想是很好的－－引入中间层永远是解决计算机问题的不二法门（大意-_-）。

对于为什么SOA如此被滥用，我想最主要还是由国内的IT环境所致。

国内的IT行业发展时间比较短，大部分应该都属于新建应用。在这种情况下，其实SOA多数应该做为前瞻性的准备工作来做，更多应该在规划好应用打好基础上下功夫，方便以后真正开始实施SOA的时候，各种应用能够很快很容易的就暴露有价值的服务出来，并且快速组合为新的应用，或者是能很快地变更应用流程，实现新的业务目标。

然而为了赚到银子，大部分厂商都拼命往自己的东西上加卖点，往往忽视了实际情况到底需不需要；很多客户也不知道自己到底需要的是什么，只好很盲目地挑哪个名词多哪个叫的响，选哪个厂商。有实力的厂商迫于压力，你有实力还不如人卖点多，不如人功能炫？于是也只好喊得更响。恶性循环！

相比来说，外国(欧美)的IT行业发展了几十年，已经有很多应用在生成环境运行着，客户基本上都知道想要通过IT系统达到什么样的目的，他们相对理性，花多少钱就要得到多大的收益，这也是他们在谈论SOA时很强调ROI的一个原因所在。这时候他们谈论SOA很有目的性，知道是要通过SOA的方式来快速响应业务需求来赚更多的钱。在选择SOA实现方式的时候也很有针对性的比照自己现实情况来做。国内上马SOA强调ROI吗？上马IT系统强调吗？

就甲方来说，与其跟风，不如静心规划好应用，让IT投资真正体现出价值，同时给以后扩展留下余地。就乙方来讲，流行概念当然也要跟进，做好技术储备，但绝不能拿客户的钱做试验，需要方案的时候能很快拿出。各位战斗在和泥搬砖第一线的同学们最好是两手抓，专心手头工作，跟紧技术趋势。对待新技术我们的口号是：不盲目，不掉队，不排斥。

ESB、BPEL、SCA简单区分 就我目前的理解，SCA其实是把其他各种服务引入自己应用的工具。 举例来说，现在有A->JEE(EJB/JMS/..)的应用（服务），B->BPEL(..) process，C->Web2.0 Component(Widget/json/..)，如果现在要做一个建立在A、B、C基础之上的应用，那么SCA是一种最合适的工具，它用类似的方式，把三种不同类型的服务引入系统，避免了维护三种不同服务接口的工作量。 而作为发布服务的工具，SCA其实是不太合适的。 再举例 已有应用是Web2.0类型的。现在要发布出一个服务，不管我是选择RESTful的，还是widget，还是json，都有相对应的简单工具，为什么我要引入SCA这么大型的工具呢？就好比现在我就想剪指甲，非买个瑞士军刀来剪，我觉得酷，你也看我像装13对吧？（又举例，真是一例解千愁啊） ESB和BPEL都有他们各自的应用场景，直接拿来和SCA比较并不太合适，而且他们也不是同一层次的工具。ESB是要解决服务通道，BPEL要解决服务流程，SCA要解决服务装配。 BTW: 这篇B文是在一个Google Group里的回帖。贴在这里主要是觉得，还稍微有点价值，而且还有很多可以发挥的点，以后说不定可以做成一篇大大的B文。

ESB BPEL and SCA, the simplest differencation
ESB、BPEL、SCA简单区分
就我目前的理解，SCA其实是把其他各种服务引入自己应用的工具。
举例来说，现在有A->JEE(EJB/JMS/..)的应用（服务），B->BPEL(..) process，C->Web2.0 Component(Widget/json/..)，如果现在要做一个建立在A、B、C基础之上的应用，那么SCA是一种最合适的工具，它用类似的方式，把三种不同类型的服务引入系统，避免了维护三种不同服务接口的工作量。而作为发布服务的工具，SCA其实是不太合适的。
再举例 已有应用是Web2.0类型的。现在要发布出一个服务，不管我是选择RESTful的，还是widget，还是json，都有相对应的简单工具，为什么我要引入SCA这么大型的工具呢？就好比现在我就想剪指甲，非买个瑞士军刀来剪，我觉得酷，你也看我像装13对吧？（又举例，真是一例解千愁啊）
ESB和BPEL都有他们各自的应用场景，直接拿来和SCA比较并不太合适，而且他们也不是同一层次的工具。ESB是要解决服务通道，BPEL要解决服务流程，SCA要解决服务装配。
BTW: 这篇B文是在一个Google Group里的回帖。贴在这里主要是觉得，还稍微有点价值，而且还有很多可以发挥的点，以后说不定可以做成一篇大大的B文。