SOA Patterns simple impression

《SOA Patterns》读书笔记

SOA Patterns》这本书出了有几个月了,可惜一直没找到下载。最近在 dzone.com 上找到一份refcardz ,得以管中窥豹。本文简单的介绍下这本书都写了什么,以及在我眼中哪些章节更值得期待。
另外,希望有这本书电子版的同志们能发我一份-_-

Do not abuse SOA

SOA之滥用

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

注:本文已发表在《软件世界》二〇〇九年第四期。

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文。

Define better web services interface

定义良好的web services接口

1, 接口是自说明的。2, 服务接口粒度要合适。3, 接口参数要尽量简单。4, 接口参数不应该增加客户端和服务端的耦合性。5, 要提供对接口参数和返回值的校验。6, 接口的返回值应该是简单的语言无关的。 7, 谨慎的抛出异常。8, 接口要尽量采用更新的标准。9, 要注意标准的通用性。10, 接口要测试方便。