Note: SOA乃唬人之宝，当厂商说客户傻（忽悠客户）的时候，客户或信或疑的应答，当真正明白过来发现已经投资无限牢牢套住，于是乎大呼：啊！

    WSDL 在增强应用之间的可连接性以及互操作性方面迈出了一大步。然而，WSDL只关注了服务接口，它并不提供描述一个服务所依赖的其它服务，以及这个服务所需要使用的配置策略和服务之间的依赖关系。

    单独通过WSDL 很难实现服务之间的组合调用。
SCA比WSDL走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。
    服务模型提供了比WSDL更多的功能，它允许服务开发者不单定义服务的接口而且还可以定义 这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略还有服务所可能提供的配置功能。

    ----这是SCA的由来。

    过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。
    这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。
    目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。
    但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。
    事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。
    这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。

    ----这是SDO的由来。

    SOA提供了一种很好的改变现有业务流程模式的途径，成功实施SOA项目的关键在于分析重点、减低风险，给出企业真正需要的功能模块。本质上讲，SOA并不是一种新技术，它仅仅是一种系统设计/规划模式，甚至可以说，只是一种现有业务流程重组转换模式。
   更直接地说，有一种需求变得越来越明显：业务需要集成系统，并允许消费者利用基于标准的方法访问服务。
    ----SOA本义

 简单的讲，SOA就是将现有的一些功能模块打包成独立的程序包，命名为“服务”模块。对于这些服务模块，需要对其接口进行良好定义，使得其他的应用系统可以使用“拿来主义”，方便的使用这些服务模块。通过创建服务模块库，将所建立的模块集中到模块库中，这样，利用库中的服务模块，可以方便的构建出所需要的应用系统，
    面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。
    基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统; SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。
    ---- SOA和现实及技术的关系 


    软件企业的产品开发和营销必须两眼紧盯着市场需求，产品开发要和市场人员紧密结合，找到关键客户普遍而又重要的共性问题。产品源于市场，服务于市场，研究技术是为了更好地解决客户的问题。

    技术是手段，附以方法论，形成BEST PRATICE，驱使的目标或目的才是关键
    目前国内大肆渲染的soa(sca,sdo)等，无非是手段，真正能派上用场的场合确实有，但是是大多鼓吹或爱好者所罕遇的。
    研究技术是为了更好的解决客户的问题，这便是技术的目的！
    -----技术的目的

最近我在做有关ESB的开发工作，发现我们的产品（开源的Celtix  http://celtix.objectweb.org） 要支持JBI和SCA两个标准。这让我困惑了好久，JBI和SCA有什么区别呢？

前几天好好在网上收罗了一番，现在把收获到的东西和大家分享一下：

JBI definition http://www.theserverside.com/news/thread.tss?thread_id=35053

SCA 与JBI的区别 http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

上面的链接有详细的讨论，我简单整理了一下。

JBI 的由来

Java One 2005 had a very heavy emphasis on JSR-208, Java Business
Integration. However, he says, "there seemed to be some folks with
confused looks on their faces in some JBI talks." As a response, he's
written a blog entry on what JBI actually is
<http://radio.weblogs.com/0112098/2005/07/07.html#a530>.

JBI是提供了一些简单的API定义， 这些定义包括 Normalized
Message Service , 在一个Router组件，以及一个管理模型用来管理服务
的部署集成，例如  routing engines, BPEL engines, rule systems, transformation engines

JBI提供了一个逻辑的XML消息网络， 这一网络能够很容易的映射到
HTTP, email 和 JMS/MOM ，并很方便地适应遗留系统，二进制地传输，
和RPC系统（EJB和CORBA)。 JBI可以看做是对JMS的更高层次的逻辑
抽象，并提供了不同的消息交换方式（ 单步， 请求应答等）

什么是SCA ，它试图解决什么样的问题？
WSDL 在增强应用之间的可连接性以及互操作性方面迈出了一大步。

然而，WSDL只关注了服务接口，它并不提供描述一个服务所依赖的其它服务，以及这个服务所需要使用的配置策略和服务之间的依赖关系。

单独通过WSDL 很难实现服务之间的组合调用。

SCA比WSDL走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。

服务模型提供了比WSDL更多的功能，它允许服务开发者不单定义服务的接口而且还可以定义 这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略 还有服务所可能提供的配置功能。

一个SCA模型对等于一个SOA项目，模型允许开发者组装一组服务组件，解决引用依赖和使用策略。这是一个很大的进步，因为当前的SOA平台需要开发者自己获取那些私有的服务部署引用，甚至有时要在他们的服务实现中写hard code.

SCA与JBI的区别

SCA的美丽之处在用它关注的重点只是SOA开发者所看到和接触到的。
SCA并没有关注用来执行SCA模块的runtime是如何构架的。
这个runtime可以实现为一个将所有的SCA服务组件编译成为Java classes的丑陋的单一服务，或者是一组模块化的引擎（每个组件一个的那种），这些引擎可以通过一个企业服务总线来进行通讯。

JBI从另一个方面来说就是一组关注创建一个开发的，可扩这的以及标准组件的企业服务总线。 这样它的内核是和SCA有一些重合的地方。同时两者之间也存在互补的机制。

说它们互补，为什么不把他们绑定在一起呢。这里有两方面的原因。
第一个原因 是JBI关注的是如果将一组引擎组装并运行 于一个JVM中。 相反SCA在另一方面并不将一个模块约束单个JVM中。 一个SCA模块可以执行在一个JVM中，同时它也可以很方便的将这些引擎部署在不同的进程甚至是不同的节点上。
第二个原因 是SCA不但支持Java而且还支持C，在今后也许还会支持C#,php。 而JBI只是SCA的一个实现方式，而不是唯一的选择。

====================================================
多少年来，Three Tier的架构似乎已经成为了教科书式的软件体系范本。它不断地提高软件灵活性和高聚合性的，时至今日，当软件复杂度更上一个数量级的时候，这种体系也开始孕育又一次重生。这就是最近的Buzz Words: SOA，也即SCA + SDO

　　受CHRIS在BLOG上所托，稍微关注了一下这方面的。

　　其实SDO已经有比较长的历史了，IBM去年就在从事该规范相关的开发。

　　而SCA相对来说更新鲜一些，主要是针对在面向服务的计算环境里，组件的实现方法。同时，它强调了这些组件与现有的平台，组件之间的关联，并描述怎样通过已有的技术、平台甚至于现有的组件来实现面向服务组件。另外，在将这些服务组件实现以后，它们的接口以及这些接口的语义是怎样描述的。其实，新的组件描述应该是技术独立、平台独立、语言独立的，也就是说它是一个开放的规范，这样就可以让很多IT厂商在不同的平台上用不同技术和语言来参考和实现这些技术。

　　除此之外，面向服务的组件需要相互之间的交互，这种交互应该是松耦合的，也就是说需要打破过去那种紧耦合的现象。因为不管是.NET、J2EE还是更早的CORBA等技术，它们在支持分布式计算时，其组件往往和平台、语言以及实现技术紧密相关。

　　过去，如果一个组件要调用另外一个组件的功能，它需要知道后者的接口在什么位置，使用什么协议和消息格式，这往往与其实现技术有直接的关系，所以技术、平台、语言和位置等各种各样的因素的透明性对于组件之间的交互就是非常重要的一件事情了，而SCA恰恰就规定了这一部分的内容。

　　另以方面，SDO其实与SCA是一对具有对应关系的规范。我早先就说过:软件=服务+数据。SCA更加关注业务逻辑，而SDO则更侧重于业务数据。

　　过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。

　　这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。

　　从技术上看，SDO规范做了如下几件事情:它定义了一个连接器，可以使用JDBC、ADO等各种不同的方式去和多种数据源交互，数据源也是多种多样，不单单局限于关系数据库，也可以是不同类型的XML文件，甚至是内存中的一块区域。同时它还提供诸如连接池、缓存(Cache)、断开连接时数据访问(Disconnected Access)等高级特性，提供了跨越B/S,C/S的边界。

    另外，SDO还定义了一个中介转换器(Mediator)，它与连接器交互，来完成数据持久化的工作，这个协调器能够理解我们定义好的Schema，让程序员能直接看到一个直观的对象图表(Object Graph)。它根据业务的语义定义一个完整的Schema，不仅能清晰地定义各种数据对象，而且还能有效地描述各种对象之间的联系，充分利用了XML强大的自描述能力。通过它，人们可以很方便的操纵数据对象。

　　综合起来说，SCA/SDO都是基于已有的技术，它们所要做的就是怎样在现有技术的基础上，为异构、分布的松耦合计算环境提供一个统一、开放的组件及其服务的描述。

　　IBM在其SCA的实现中，也就是WPS 6.0所提供的SCA运行时环境，有多达八种不同的组件实现形式可供选择。我想更理想的实现应该是提供一个可以扩展的接口。即使在语法上、数据结构上有很大的不同，甚至是某公司自己语义上的东西，也可以方便地纳入SOA的架构里。

　　这样一个规范目前受到了IT技术主流的技术厂商的支持，它的建立为基于SOA的下一代计算环境下的编程模型打下了一个坚实的基础。

　　与古老的CORBA技术(请允许我用这样的词来描述它，呵呵～)想比，两种技术的背后都有很一致的哲学。但是受限于当时的技术发展条件，我们回顾历史的时候，CORBA在很多细节上的处理并不是太好，而且，CORBA是基于面向对象思想的，与之不同的是SCA基于面向服务的思想，其实抽象程度要相比过去的提高很多。

　　这里我引用一下Gartner的报告:

• 　　随着商业和技术的推动，SOA将成为将来的发展趋势已经没有人怀疑了;
• 　　2007年，超过50%以上的公司将SOA作为IT战略来考虑;
• 　　2008年还没有将SOA引入到公司的IT实现中去，那么该公司将成为一只恐龙，也就是说这个公司很落后了。

　　目睹这些年软件的迭代更新，我有时也在想，是不是这就是软件自己的“摩尔定律”，所不同的是，用来度量软件的不是单晶片上可以集成的晶体管数，而是单个软件工程师所能Handle的软件复杂度，姑且叫它"logic per brain"吧。 

大家有没有想把 axis 嵌到自己产品中去的？

我有一个理想(24332715) 23:08:13

如果SCA构件分布式的部署在多个应用服务器上，那么在装配中

我有一个理想(24332715) 23:08:24

SCA的服务结构

我有一个理想(24332715) 23:08:35

接口

我有一个理想(24332715) 23:08:43

使用WS定义

我有一个理想(24332715) 23:08:57

那么装配出来的应用效率是不是很低

david(172171) 23:09:12

可以认为SCA的容器是一个bean

我有一个理想(24332715) 23:09:47

没懂

david(172171) 23:10:52

sca容器宿主在Tomcat上,通过sca可以引用其它分布的应用

我能否用 bpel 流程来引用SCA呢？

david(172171) 23:11:42

可以

david(172171) 23:12:02

这个问题在那个群里已经讨论过了

我有一个理想(24332715) 23:12:23

通过宿主进行的引用？

david(172171) 23:12:28

对

david(172171) 23:12:30

http://blog.csdn.net/teamlet/archive/2007/03/22/1537510.aspx

我有一个理想(24332715) 23:12:37

谢谢

david(172171) 23:12:56

从这个图中可以看出 SCA中的component和bpel的关系

david(172171) 23:13:52

sca的component/(composite: cuiyi add)对外提供粗粒度的接口,bpel通过implementation提供细粒度的实现

david(172171) 23:14:09

sca是bpel更高层次的抽象(bpel is implement technology, sca is a component, compent is interfaces, one for expose, another for reference,就是下面的棍/坑说啦，cuiyi add)。

我有一个理想(24332715) 23:14:38

bpel是SCA的服务实现

我有一个理想(24332715) 23:14:45

是一种

我有一个理想(24332715) 23:14:50

这么理解对吗？

david(172171) 23:15:10

是的，是其中的一种

 

david(172171) 23:14:57

component只不过是sca装配模型中最基本的组件单元，上面还有composite，domain

david(172171) 23:15:36

想用bpel调用sca是可以的，但是大才小用了

david(172171) 23:16:45

实现包括 , C++, PHP, Java Script, BPEL, SQL, XQuery, Composite，ruby

david(172171) 23:17:12

当然还有java

我有一个理想(24332715) 23:49:42

SCA Component 它有一个壳，壳上Service，Reference,property，壳里边包含的东西连接着Service，Reference,property，壳里边的东西就是这个Component的implementation(not exactly, cuiyi add)，implementation可以是很多东西，java，c++等等什么都行，这么理解对不对。

两块田(7739638) 23:52:39

很对

我有一个理想(24332715) 23:56:40

壳上的Service就是指出来的棍(凹进去的坑,引用找服务，就像棍插坑，cuiyi add)，Reference就是凹进去的坑（凸出来的棍），棍插坑，坑插棍，几个连一起，还有坑还有棍这时候是合成组件(Composite)，对不?

两块田(7739638) 23:57:14

说得有点色了~:)

我有一个理想(24332715) 23:57:23

哈哈

我有一个理想(24332715) 23:58:33

再整几个只有棍的，还有只有坑的，把Composite的棍和坑插满，就是系统域(Domain)

两块田(7739638) 00:11:24

兄弟研究棍和坑研究得挺深啊.

我有一个理想(24332715) 00:11:38

两块田(7739638) 00:12:02

重要的是可以插进去,插出来又可以用到别的坑里~:)

我有一个理想(24332715) 00:13:48

嗯

the following add by cuiyi, 系引用

开-闭”原则（Open-Closed Principle）是面向对象的可复用设计（Object Oriented Design或OOD）的基石。其他设计原则（里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则）是实现“开-闭”原则的手段和工具。 

“开-闭”原则的定义

定义：一个软件实体应当对扩展开放，对修改关闭。
( Software entities should be open for extension,but closed for modification)。

在设计一个软件系统模块的时候，应该使这个模块可以在不被修改的前提下被扩展，或者说，可以在不必修改原来代码的情况下改变这个模块的行为。

满足“开-闭”原则的系统的优点

1)通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。
2)已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
具有这样两个优点的系统是一个在高层次上实现了复用的系统，也是一个易于维护的系统。

“开-闭”原则的实现——抽象化

面向对象编程语言可以使用抽象的方法，为系统定义一个不再更改的抽象设计来作为系统的抽象层。这个抽象层覆盖了所有未来可能扩展，因此在任何情况都不会改变。这样使系统的抽象层保持不变，从而满足了开闭原则的第二点：对修改关闭。

由于从抽象层导出的一个或多个具体类可以改变系统的行为，因为系统的设计对扩展是开放的，从而满足了开闭原则的第一点：对扩展开放。

在SCA框架中，无论在commonj还是SPI；无论是composite还是component，都可以看到开闭原则的应用。

remark by cuiyi

I feel Component in SCA just a restriction according to DP, so exposed as interface or web service description language (XML), just made DP a restriction to developers, meanwile, the systems developed on it can be more extensice and integratable; 即：
SCA 提供一个以与技术无关的方式定义接口、实现和引用的模型，从而使技术人员能够将这些元素绑定到所选择的某一技术的特定实现。

例如，我们可以用 Java 定义我们的接口，将我们的实现作为 BPEL 流程加以应用，或者将接口作为一个 WSDL 文档，而且我们的实现可以是一个 Java™ 类。下图 演示了如何在 IBM WebSphere Process Server 中使用 SCA。
图. WebSphere Process Server 中的 SCA

○分离业务逻辑和技术实现逻辑
○业务过程由松散耦合、可重用的组件或服务组成
○组件或服务与平台和实现无关

goCom SCA规范综述
实施SOA不意味着要推翻既有的架构，比如MVC，而是要在现有架构上做更大的架构。

传统的MVC对于单个应用来说非常成熟，这是实践中证明的。对于大多数独立的应用和系统来说MVC很胜任。然而，当企业中的应用规模不断扩大，从几个到几十个甚至上百个的时候，靠若干MVC架构的不断叠加能够构造出一个适合企业级的架构么？所以才出现了Portal这样的新技术来迎接这样的挑战，但是Portal的关注点更靠近与展现端，在底端通讯方面不能给出更好的答案。所谓架构是要一套整体解决方案，这样的架构所要解决的问题简而言之就是两个特点：数目或规模大、异构应用交互。

　　1. 为什么不同的人对SOA有不同的解释?

　　SOA 的定义取决于你在组织业务中的角色。

　　对于业务执行人员，SOA创建了企业希望向其客户和合作伙伴或组织的其他部分公开的一组服务。对于IT架构师，SOA是一种体系结构样式，此样式至少需要有服务提供者、请求者和服务描述。对于程序员，SOA是一个由标准、工具和Web服务等技术加以补充的编程模型。

　　当然，企业信息技术系统及流程管理人员之所以存在似是而非的SOA概念，还可能因为软件厂商没有向企业用户解释清楚SOA的含义。比如，SOA 中的服务(Service)并非我们理解的传统企业服务，而是软件开发的专业用语，指技术层面的、细颗粒度的功能模块，还远未达到与企业业务流程直接对应 的程度。软件厂商在强调SOA给企业带来巨大商业价值的同时，并没有具体阐释这一点。

　　2. 业务流程管理(BPM)和SOA是何关系?

　　BPM与SOA既可以单独部署，也可以组合使用。

　　如果企业的IT系统比较简单，企业规模比较小，用同样的一组IT人员就可以控制所有IT系统，那么，部署一个不使用SOA的BPM套件，就可以 获得快速创建、执行和监控/管理业务流程的能力，而不必部署SOA。但是，如果BPM套件由一个IT小组部署，而同时使用来自另一个IT小组的系统服务， 那么SOA就可以帮上忙了。

　　如果企业的IT系统足够复杂，可以考虑将BPM和SOA组合使用，通常在SOA上实施BPM解决方案可以获得更大的业务灵活性。如果BPM项目达到一定的范围和规模时效果才能显现，最好先开发出BPM，而将SOA组件留待以后考虑。

　　最好一开始就让业务流程团队和IT架构团队保持持续良好沟通，针对未来进行可行性规划。例如，BPM套件本身应该能够提供丰富的连通性，以便无需全面应用完善的SOA来使得BPM运行，不要让BPM与SOA成为互不连通的两套系统。

　　3. “瀑布式”开发与迭代式开发哪个适合SOA?

　　企业部署SOA最好是通过迭代模型来实现。

　　迭代模型将标识一组对业务非常关键且价值高的功能来进行服务支持工作。此模型可随后供后续服务支持项目和活动使用。如果采用传统应用程序开发时使用的“瀑布式”开发方法部署SOA，可能导致创建仅能部署一次的服务，而无法在以后对其进行重用。

　　使用迭代式开发部署SOA，可通过允许组织逐步纳入到系统中，从而减少出现业务故障的风险。同时，任何组织接受和容纳更改的能力都是有限的，迭代式开发可确保引入新的流程和系统带来的更改非常适应企业的容量，且不会在企业中引起大的混乱。

　　同时，在SOA中，新功能并不一定总是仅受单个业务部门(Line Of Business，LOB)的约束，需要考虑很多跨组织的依赖关系，迭代式开发也有助于解决跨组织的协调。

4. Web服务与SOA是一样的吗?

　　Web服务仅仅是目前最流行的SOA实现技术，但并非可以用于开发SOA的唯一技术。

　　SOA与Web服务(Web Service)的数量无关。对于SOA来说，真正有价值的是对于Web服务的再利用而不是Web服务本身。即使将所有信息技术系统都用Web服务实现， 也不见得就等于部署了SOA。有些企业使用了太多的Web服务来做同样的IT服务，结果部署SOA的效果非常差。将Web服务等同于SOA，很容易发生在 一些希望快速实现SOA但是并未真正理解SOA的企业身上。

　　很多SOA项目都涉及到集成遗留数据，此类数据包含在使用MQSeries和CORBA(Common Object Request Broker Architecture)等“旧”技术的系统中。其中的许多技术都已针对SOA进行了调整，不管有没有Web服务都可使用。事实上，企业可以只使用 MQSeries、CORBA甚至远程过程调用(Remote Procedure Call，RPC)技术就能实现SOA。

　　5. 所有应用程序或环境都适合部署SOA吗?

　　不是所有的应用环境都适合部署SOA，很多情况下，部署SOA的效果可能会适得其反。

　　SOA可以根据需求通过网络对各种应用组件进行分布式部署、组合和使用，从而满足用户统一服务界面、快速部署新业务等需求。但是，如果企业的 IT系统并不复杂，系统基本上都建立在同一架构上，整合系统并不困难，那么实施SOA并不能给企业带来太多好处，反而可能会带来负面影响。

　　专家认为，针对某些应用程序或IT环境，SOA可能并不值得推荐。比如，不需要组件或者应用集成的、独立的、非分布式的应用程序;应用范围非常 狭小或者生命周期短的应用程序;建立在同一架构上的应用程序环境等等。对于一些企业来说，采用了单一厂商的技术和产品，拥有同一架构的IT环境，就不需要 那么急迫地实施SOA，或者实施的效果并不是很明显。

　　有些企业很多年前就已经成形了业务支撑系统，虽然经过了很多次修修补补，但都一直在正常运作。专业人士认为，这种结构老、补丁多、又肩负重任的系统，与其用SOA动大手术，还不如等这种系统寿终正寝，重新开发符合SOA架构的新系统，进行自然淘汰比较好。

　　6. 企业应该如何着手部署SOA?

　　部署SOA应该制定明确的路线图，循序渐进。

　　企业部署SOA时最好先制订一个清晰的路线图，然后从单个应用程序开始构建SOA架构，可以先从比较简单的应用开始。这样，企业可以在做出全面部署SOA之前先衡量投资回报率，并在出现大的问题之前积累足够的经验。

　　当企业计划部署SOA项目时，CIO要注意各种细节，比如，供应商提供的软件是否支持Web服务和SOA;开发某些应用程序时，该应用是否要支 持其他业务需求;哪些应用需要嵌入对Web服务的支持等。如果企业大规模部署SOA，还需要建立企业服务总线(ESB)，通过ESB提供服务请求。当然 ESB的建立也需要一个过程，CIO必须注意部署节奏。

　　尽管目前已经可以找到很多关于SOA的知识，但部署SOA仍然非常困难。其中最直接的原因在于SOA需要企业部门之间的高度沟通，而且要求整个 企业都为变革做好准备。变化带来的问题解决之后，可能又会出现技术问题。因此，企业部署SOA需要提前做好各种各样的准备，并且有长期的详细计划安排。

面向构件的概念着眼于软件的构造，其语义内涵包括：
1、层次化。软件呈现层次化构造，整体可以由一系列有内在结构的器官，即构件，构成。而构件可以由更小的构件构成。
2、可复用。这些构件可以在不同的软件中以相同的形式出现，完成大致相同的功能。

SOA概念着眼于软件的功能，其语义内涵包括：
1、层次化。软件的功能呈现层次化复合，综合功能由单项功能复合而成，复杂功能由简单功能复合而成。
2、可外化。一个软件需要的功能可以由另一个软件提供。

由于“功能外化”可以看作是互联网时代功能复用的一种形式，面向构件与SOA完全同构。
因此，我们说SOA从面向构件开始，就是SOA通过面向构件去实现，因为面向构件是SOA的自然实现方式。
############################################################################

读后，个人分析如下：

SOA架构体系层次结构（参见对SOA和目前业成熟应用的JavaEE应用方案的一点看法）中，构件应该是“service component”层的主要技术，其之上的层次是“enterprise service”层。（当然这个可以是系统内，也可以是系统间）

再次看一下JEE（这里聚焦在系统内），对应的就是 服务实现 和 服务接口 这个层，并一定程度上借助Facade Pattern。

因此赞成“SOA从面向服务开始而又基于构件的”的说法。

首先在“我对SOA的认识（二）<http://www.blogjava.net/crazycy/archive/2006/05/24/47799.html>”中提到了方法论的问题：

*******************************我对SOA的认识（二）**文始************************************************************

    对于方法论，查了一下大概阐述如下：方法论是一套完整的实践引导体系，是指导实践的理论基础，是人们在长期社会实践中总结和摸索出来的，符合客观发展规律的，符合人们对研究对象进行科学分析与判断的社会实践进程或步骤。方法是实践的成果，如同瓜熟蒂落，实践积累达到一定程度，必然会提出方法。

    阅读周爱民先生的《大道至简 — 软件工程实践者的思想》时，其对方法、方法论也有阐述，摘录如下：
++++++++++++++++++++++++++++++++++++++++《大道至简 — 软件工程实践者的思想》++文++++++++++++++++++++++++++++++++
3. 方法

    推动这种逻辑向前发展的，是 “ 方法 ” 和 “ 方法论 ” 的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种 ( 软件开发 ) 方法，于是 “ 过程 ” 出现了，于是 “ 对象 ” 出现了，于是相关的方法论也就出现了。

    这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出某个方法， IBM 也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。

    方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如 “ 模式 ” 是一种方法，而模式就是你昨天书写代码的那个行为。只不过， GoF 归纳、抽取、提升了这些行为的内在规律。

    你看不到你做事的行为，也就不能理解 “ 模式 ” 作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。

    同理，理解过程也需要编程经验，理解对象也需要编程经验，理解 MDA 与 SOA 还是需要编程经验。

    —— 这可能就发生在你去回顾你上一行代码编写的经过，或者上一个项目失败的经历的那一瞬息。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

    有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。

    GoF 因为无数次的代码回顾而得道。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    同样在业界，任何一种技术或者架构的产生，都是历史潮流的产物， SOA 概念的提出也是业界面临的新问题的解决过程，尤其表现为不同语言开发的组件的相互调用，大型系统与大型系统的连接问题。

    正是伴随着软件系统发展的需求，催生了SOA的诞生。这也导致SOA的核心就是将多个系统连接和整合起来，达到大集成的目的。

    这种思想的产业化，就是业界大型公司的服务解决方案，SUN通过收购推出自己的SOA服务并有开元的打算，IBM利用自己的全套软件产品全方位的提出了自己的SOA应用，类似的Oracle、Redhat等或者通过收购或者利用自己的产品线推出了自己的集成方案。WebService（WSDL、SOAP、UDDI）就是SOA体系的一个具体技术解决方案，由于产业界都有共同支持，也就成了SOA下当仁不让的红人，外加各种相关规范的辅助，偏激一点的说，SOA就是思想体系，WebService就是实现技术。

    在《我对SOA的认识（一）》中，我提到过对于SOA的概念和理解仁者见仁，当然不排除受这些思想体系产业化后的影响。毕竟企业提供服务是为了更好的生存，而不是“免费的午餐”。

    类似OOP、AOP一样，SOA也不是一种产品或者组件，而是一种理念，一种系统设计的理念。SOA体系下提供的是服务，服务和服务间通过端口（Port）等连接在一起，从而从一个全新的角度去观察、设计系统。
*******************************我对SOA的认识（二）**文末*****************************************************************

很明显方法论角度已经论及了SOA的出现的历史需求，是一种切实的需求，而非仅仅是一种炒作，当然存在炒作成份。常听及“旧瓶装新酒”，无可厚非，技术原本就是在原有基础上不断完善直到革命因素的出现。这也是方法论，呵呵。
例证说明：WSDL对WS的描述通过5大标签<types><messages><porttypes><binding><port>；无非就是把一个类的调用方式（方法名、参数、返回值）用XML文档描述而已。

    SOA的出现与成熟必然要有它的技术支撑体系，SOA解决了一个互操作、协同业务这样的技术层面的问题。
    a） 互操作：可以理解成把语言级的接口---〉XML通用标准下的WSDL； 
    b） RMI的远程调用----〉XML和XSD辅助下的SOAP；
    c） 协同业务---〉ESB、BPEL、UDDI来完成；服务发布于UDDI，业务流程的编排通过BPEL来组合服务，运行时服务的定位路由和交互由ESB完成。
    d） 服务的具体实现，即应用程序的不同功能单元的联系（接口、参数/约定）---〉SCA、SDO技术

厂商关注的则是其产品体系和在业界的影响，对SOA进行一定的炒作自然情理之中，但简化SOA的开发、普及SOA应用、解决SOA基础设施，这些产品应该说功不可没。

综上分析，可得出，提到SOA时，首先最重要的是其思想方法论，其次才是技术和产品，应该说SOA是方法论+产品+技术的综合体。

非常感谢你的阅读，如果你觉得好或者对你有帮助，请积极给一个留言反馈以示鼓励。  

提到这个话题，不免得提及Java设计理念，以及与Web Service可移植性密切相关的三个JSR规范：JSR1.9、JSR175、JSR181

提到可移植性，我们又不免想到如下方式：
    ①XML配置文件屏蔽差异，类似Facade Pattern的形式统一入口
    ②注释
    ③类似JBoss提出的Micro-Container

我们进入正文：

Java一个理念是：Write Once， Run AnyWhere。Java哲学：Java追求平衡的哲学--即简单和力量的共赢。
    从目标可以看出可移植性是Java的一个设计理念。
    但Java世界的可移植性束缚苦恼着许多跨应用服务器的开发者、部署者。

JSR109
    A. 目标：以一种可移植和互操作的方式为J2EE构建和访问Web服务（即Web Service在J2EE上的实现）。它指定了下面的条目：
        a. 客户端编程模型：无论客户端如何访问Web服务，Web服务就像一个普通的远程对象一样（即J2EE如何把Web Service作为传统的远程对象来访问）；
        b. 服务器端编程模型：Web服务怎样作为SLSB或JAX-RPC形式的Servlet实现（即怎样用Servlet和SLSB来实现Web Service并使Web Service具有和它们一样的生命周期）
        c. 部署模型：使用部署描述符来定义可以在所有符合J2EE规范的应用服务器之间移植Web Service（即如何在应用服务器上部署Web Service）
    B. 个人观点：a、b两点表现尚可，c着实不让人满意，因为实现互操作的目标没有问题，但是可移植性着实难以让人满意，问题关键是：部署描述符：
    C. 疑问：为何JSR109不明确规定部署描述符的明确XML Schema，尤其是文件名、文件的标签、以及部署的文件个数。

JSR175（Java语言元数据工具）
    A. 目标：用于 Java 编程语言的元数据,就是使用注释编程
    B. 个人观点：①简化了开发尤其是配置文件 ②可移植性成为可能 ③类似“静态类”机制成为可能
   说明：只要加载了类，类中的注释可以是运行中的，加载类的时候完成了配置，而这个加载可以是入口函数的调用、可以是Servlet加载。
            我们知道只要加载了类，静态类变量、静态方法就自动被初始化到内存中；同理，要是有“静态类”.......
    C. 疑问：注释能否像接口、类那样进行功能自定义化呢？！
    D. 摘录：
    JSR175仅仅有少量的注释类型变量，而这些有趣的注释类型变量主要来自于其他的JSRs：
        •JSR 250: Java平台的公共注释
        •JSR 220: 企业级JavaBeans 3.0
        •JSR 224: 基于XML的Java API Web Services (JAX-WS) 2.0
        •JSR 181: Java平台的Web Services Metadata

JSR181（Java Web服务元数据）
    A. 目标：致力于Java Web Service。
        基本理念：Java Web服务仅仅是带有某些标注的普通Java对象（POJO）。使用带有Java标注的Java语言编写Web服务，并且任何符合规范的处理器都能处理这些标注，并生成适用于目标运行时环境的Web Service。
        涉及范围：
       ①定义用于进行Web服务应用程序编程的带注释的Java语法
       ②提供可促进和加速开发的简化Web服务开发模型
       ③提供可通过工具进行操作的语法
       ④定义构建和部署Web服务的标准，而无须了解通用API和部署描述符的知识和使用相关实现
    B. 个人观点：由于规范没有指定web服务的运行环境，只提供了一个处理带注释的java文件的模型，以及到Java EE运行期间的环境的映射。这不免又存在不可移植性。

本文主要谈论可移植性，我们首先分析为何会出现这个现象？

首先我们知道J2EE中，部署后的应用程序的入口是META-INF文件夹，而这个文件夹下的部署描述文件则带有基本的描述信息。
在Web Service中， META-INF下具有部署描述符：webservices.xml和jax-rpc-mapping.xml；以及服务描述文件.wsdl。
    webservices.xml依然没有逃脱出JSR109在可移植性不足的阴影，那我们可以知道，由于WSDL是国际规范，XML Schema明确加以描述，只要消除了部署描述符的差异，可移植性必然增强。
    那如果没有部署描述符如何？
    首先，我们来分析webservices.xml的作用：Web服务入口下的webservices.xml告诉容器在何处查找WSDL，以及将什么接口和实现用作Web服务。
    同时，我们知道这些信息的解析起到了一个注册表的作用:map(uri-wso对象) wso对象包含:wsdl文件,jax-mapping文件,服务接口、实现类，等。
    那我们有两种策略：
　　①运行中生成部署描述符－Java的注释
　　②放弃部署描述符的概念－
   
    解释第①中做法：
    JSR181处理器，一定要在运行中生成符合J2EE规范的部署描述符，而不是部署前就已生成好。
    方式<一>：静态类，部署时必然要部署java类，如果有静态类（JVM增加功能）概念，则可以通过带注释的静态类来完成。
    方式<二>：Servlet加载一个类，这个类中具备完善的注释，Servlet的加载机制必然导致类的加载，利用运行时注释生成部署描述符。
   

解释第②中做法：
    不兼容是因为没有严格的XML Schema来描述部署描述符，而入口却是这些部署描述符的XML文件；
    如果有部署描述符（包含运行中生成），无非是解析XML文件得到一个类似注册表的作用；
    我们直接由java类来生成这些内存注册信息，而不是通过运行时注释。
    方式<一>：静态类，部署时必然要部署java类，如果有静态类（JVM增加功能）概念。
    方式<二>：Servlet加载一个类，这个类中具备完善的注释，Servlet的加载机制必然导致类的加载，利用运行时注释生成内存注册信息。
    这两种方式不由得想起是否可以在META-INF下放置一个类？
    是否可以类似Servlet机制，从Class-Loader入手？
    是否可以继续改进JVM，直接可认出直接加载的类？

    考虑到各集团的利益,可以看出JCP更多的致力于改良,而改革动作很少,改良往往意味着不能更好的满足新需求的呼唤,也埋下隐患.
   

Thanks very much to visit blog,  welcome your feedback,  your feedback is the Driver && Power to me

今天学习了IBM中国软件开发中心SOA设计中心任志宏先生关于“同IBM合作，构建SOA应用——如何使用IBM SOA相关技术、产品和服务实现一个典型的业务场景”的讲座内容，整理其框架如下：

SOA价值

1.         建立集中的企业服务总线，屏蔽具体的服务实现，保持IT系统的柔性；

2.         引入业务规则作为服务实现方式，保证系统灵活性的同时，提高工作效率；

3.         流程自动化，提供实时的流程监控和管理。

服务建模及流程建模

SOMA——IBM用于服务建模和架构设计的方法学，根据此方法学，业务组件、一级业务流程和业务目标是服务建模的三个主要输入

SOMA的执行：

(一)  服务发现

步骤：

1.         从一级流程逐步分解，找出各个层次的服务候选者；

2.         分析关键业务指标，验证已有服务候选者以及发现遗漏的服务候选者；

3.         分析现有系统，发现遗漏的服务候选者，并为服务实现提供依据；

服务发现的三个步骤获得服务候选者的组合以及服务暴露（？？？）的决定，利用输入的业务组件将服务候选者分类，为服务规约和服务实现做准备。

(二)  将新发现的服务发布到Service Registry，在企业范围内实现统一的服务管理。

(三)  利用Websphere Business Modeler进行流程建模，从业务流程、组织结构以及关键业务指标等方面，对业务流程进行全方位建模。

(四)  利用Websphere Business Modeler进行模拟，在实现流程之间发现潜在业务瓶颈，并及时进行优化，降低项目实施的风险和成本

服务实现及架构    

       要注意的几点：

(一)  从Service Registry中获取可重用的服务的相关信息，直接应用在本项目中，避免重复开发，降低开发和维护的成本；

(二)  基于服务规约和现有系统分析，确定服务实现的决策；

(三)  架构设计：将已有服务、新建服务以及服务中介按照SOA参考构架进行架构设计；

(四)  人工任务用统一的服务接口定义人工活动，提供重用人工服务的可能性

(五)  流程服务提供灵活、方便的服务组装模式，使得企业能够最大可能地重用现有服务，并快速响应需求的变化

(六)  业务规则将易变的业务逻辑从代码中分离出来，便于快速响应业务需求的变化

(七)  基于Websphere ESB的服务中介能够拉近服务提供者和请求者的差距，并提供虚拟化服务

(八)  商业化的适配器以及适配器框架采用标准化的方式解决不同应用之间的联通性问题，采用保护企业投资的方式解决复杂的集成问题

以服务为中心的开发与集成

通过使用Websphere Integration Developer，从服务模型直接映射到SOA编程模型，实现模型与实现的完美统一。

将流程从Websphere Business Modeler导入到Websphere Integration Developer，自动实现流程服务以及相关的业务对象、接口定义，提高了开发效率，并保证了模型和实现的统一。

在Websphere Integration Developer中实现人工任务，统一的安全机制确保人工服务的权限的控制，客户端设置支持工作人员通过Web页面或者手持终端设备等方式参与自动化流程。

在Websphere Integration Developer中实现基于业务规则的服务，将易变的业务逻辑从代码从代码剥离成业务规则，从工作效率和质量两方面使系统可以更加灵活的应对变化。

在Websphere Integration Developer中为服务创建中介，拉近服务提供者与请求者之间的差距，将两者的具体实现解耦。

通过使用Websphere Integration Developer，在所依赖的服务并未实现的情况下，利用集成测试客户端独立测试服务组件，从而实现快速的迭代开发。

服务部署及管理

       Websphere Process Server为流程、人工任务、业务规则等服务以及服务中介提供稳定、高效的运行环境。

       完成服务部署后，将新实现的服务状态设置为可用，使得该服务可以在企业范围内得到重用。

       基于建模阶段定义的业务指标模型和运行环境的业务事件通知，Websphere Business Monitor实时监控业务流程运行情况，并将流程运行情况以关键业务指标的形式反馈给Websphere Business Modeler，从而实现一个完整的业务流程优化周期。

服务模型分析设计(Service Model Specification Documention)

要求包含：

1 服务发现及其依据

2 服务规约

3 服务实现分析

感觉这几个要求点都有些难以很容易理解。我的理解如下：

1 服务发现和依据：主要是服务的来由，即是在什么样的业务需求下才产生的这个服务。包括自顶向下的新系统产生的新服务，和自底向上的原系统的分析产生的服务需求；两者的结合产生中间碰的思想。

2 服务规约：服务级协定（Service Level Agreements，SLA）。也可以理解成服务契约Contract 就是一种约定，这里应该是消息（SDO）

3 服务实现分析：主要是服务的接口、操作、消息。

pigcan

目前成熟的JavaEE应用，推荐三层架构：表现层、控制层、业务逻辑层[接口和实现]（可细分业务逻辑、持久化两层）。贯穿于所有层的是基础设施（安全、事务、可靠性等）。

对比JavaEE中的三层结构和MVC可以看出：

    表现层类似。可以是GUI也可以是Web。现在更崇尚Web。而且表现层（Web）一定要遵循MVC模式（注：MVC不是JavaEE的三层结构，注意区分，只是表现层的一种架构，确切的说，还不是模式）。  

SOA的业务过程合成层对应JavaEE的控制层（包括Façade Pattern）。前者把单个或者一系列服务绑定成一个控制流程，可以做为单独的应用程序使用。后者通过Façade模式将不同的组件结合起来，提供一个统一的访问口。

    SOA的服务层对应于JavaEE系统间的接口。不同的是前者是系统间，后者是系统内。但都是被发现或者静态邦定或者声明式注入，然后调用。前者对系统集成、后者对单个系统实现来说功能是一致的。但是前者的优势在于通过文档（WSDL）声明的方式屏蔽了系统、语言之间的差异性，如果是同一实现体系中不考虑异构，后者的优势在于效率。

企业组件层对应于JavaEE系统的业务逻辑层。都是负责实现业务功能、提供基础设施服务的组件。常运行于应用服务器中。

为什么要使用 SDO？

对 于服务数据对象（SDO），大多数开发人员要问的第一个问题就是为什么要使用 SDO。难道 J2EE 本身还不够庞大、不够复杂（而且难以掌握）吗？Java 环境中不是已经有其他支持 XML 的框架了吗？所幸的是，该问题的答案能够让我们多数人感到满意：SDO 是作为简化 J2EE 数据编程模型的方法出现的，它能够让 J2EE 开发人员把更多的时间用于应用程序的业务逻辑。

服务数据对象框架为数据应用程序开发提供了统一的框架。通过 SDO，您不需要熟悉特定于技术的 API，就能访问和利用数据。您只需要知道一种 API，即 SDO API，它允许您处理来自多种数据源的数据，其中包括关系数据库、实体 EJB 组件、XML 页面、Web 服务、Java Connector Architecture、JavaServer Pages 页面等。

并展开了各种技术在"拨开SDO(Service Data Object)唬人的光环"中各种技术的对照.这个文章可谓是非常及时和有力的.