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从面向服务开始而又基于构件的”的说法。