下载文档原格式
SOA代表了面向服务的架构。
如果你正在准备采取SOA，以下SOA的面试问题和答案可能对你非常有用。
基本上，这些SOA的面试题涵盖了整个SOA。
涉及SOA的服务特点和原理，服务，合同，地址和绑定的松耦合，SOA对于业务和IT的主要优点，服务与组件的差别，SOA的业务需求等等。
1. 什么是SOA的服务？在现实世界中，服务是一种我们花费购买到的一种预期的服务。
例1 （来自真实世界）：你去餐馆订餐，您的订单首先进入到柜台，然后在厨房进行食物准备，最后服务员提供的食物。
因此，为了实现一个餐厅订购服务，您需要三个逻辑部门/服务协同工作（计帐，厨房和服务员）。
在软件世界同样的方法称为业务服务。
例2 （软件世界）：你去亚马逊订购了一本书，有不同的服务，如支付网关，库存系统，货运系统等共同完成一本书的订购。
所有的服务是自包含的，合乎逻辑。
他们就像黑盒子。
总之，我们并不需要了解业务服务的内部工作细节。
对于外部世界，它只是一个能够使用消息交互的黑盒子。
例如在“支付网关”业务服务获得消息“检查信贷”后会给出输出：这个客户的信贷有或没有。
对于“订单系统”，“支付网关”的服务是一个黑盒子。
2.服务的主要特点是什么？以下是服务的SOA的主要特点：A）SOA组件是松耦合的。
当我们说松耦合，这意味着每一个服务是自包含单独存在的逻辑。
举例来说，我们采取了“支付网关”的服务，并将它附加到不同的系统。
B）SOA服务是黑匣子。
在SOA中，服务隐藏有内在的复杂性。
他们只使用交互消息，服务接受和发送消息。
通过虚拟化一个服务为黑盒子，服务变得更松散的耦合。
C）SOA服务应该是自定义：SOA服务应该能够自己定义。
D）SOA服务维持在一个列表中：SOA服务保持在一个中央存储库。
应用程序可以在中央存储库中搜索服务，并调用相应服务。
E）SOA服务可以编排和链接实现一个特定功能：SOA服务可以使用了即插即用的方式。
例如，“业务流程”中有两个服务“安全服务”和“订单处理服务”。
“soa”名词解释1、“soa”的概念SOA（Service-Oriented Architecture，面向服务的架构）：是一种在计算机环境中设计、开发、部署和管理离散模型的方法。
SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。
在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。
这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。
二、soa的特征·可重用：一个服务创建后能用于多个应用和业务流程。
·松耦合：服务请求者到服务提供者的绑定与服务之间应该是松耦合的。
因此，服务请求者不需要知道服务提供者实现的技术细节，例如程序语言、底层平台等等。
·明确定义的接口：服务交互必须是明确定义的。
Web服务描述语言（Web Services Description Language，WSDL）是用于描述服务请求者所要求的绑定到服务提供者的细节。
WSDL 不包括服务实现的任何技术细节。
服务请求者不知道也不关心服务究竟是由哪种程序设计语言编写的。
·无状态的服务设计：服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。
服务不应该依赖于其他服务的上下文和状态。
当产生依赖时，它们可以定义成通用业务流程、函数和数据模型。
基于开放标准：当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准．采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。
三、soa设计原则·明确的接口定义：接口需满足稳定、明确、封装性等要求。
·自包含与模块化：实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
SOA带你走进新时代技术服务中心贺进今天，几乎所有的软件开发人员都听说过SOA，业内所有从业人员都在探讨SOA话题，而主流的信息化应用软件都宣称自己是基于SOA架构的，我们直接面对的市场项目也无一例外的会带上这么一条“硬杠杠”：要求软件系统采用SOA架构。
那么，SOA究竟是何方圣神？它到底有多大能耐？又到底有多大难度呢？就让我们从SOA基础的概念开始，一起揭开SOA 神秘的面纱。
1SOA概念随着我国各行业信息化建设的不断深入，企事业单位逐步建立起的大批计算机信息系统和各类数据信息因缺乏有效衔接，导致信息资源共享难、“信息孤岛”现象普遍存在。
与此同时，日益激烈的市场竞争要求企业通过加快管理转型、技术创新、新产品研发以及业务策略调整等方式来提升自己的核心竞争力、持续占有并扩大市场份额。
企事业单位的这些转型方式及过程的有效实施，一方面更需要信息技术和信息化的手段来支撑，另一方面，这些业务需求也对信息技术和信息化建设本身提出了更高要求：IT系统（通常也称为“信息系统”、“应用系统”或“软件系统”等）要能快速响应用户业务发展和变化的需求，新系统必须能在充分利用用户原有IT资源基础上快速构建出来，同时要实现跨平台、跨组织的数据共享和业务协同。
基于上述背景，SOA（Service Oriented Architecture，面向服务的体系架构）是近年来软件规划和构建的一种新方法，其概念最早由国际咨询机构Gartner公司于1996年首次提出。
由于其本身特性非常符合上述信息化需求和问题的解决思路，在我国，2006年后逐步开始在多个行业信息化建设中被选择和应用。
SOA（Service Oriented Architecture，面向服务的架构）是一个组件模型，它将应用程序的不同功能单元——服务（service）通过服务间定义良好的接口和协议联系起来。
用于把企业中那些大量的遗留系统、现有系统，以及新的基于Web的应用服务绑定起来，它的本质是要实现“整合”。
SOA面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。
由于它考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与SOA 相似。
然而，现在的SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。
软件设计中的面向服务架构（SOA）当今互联网时代，软件开发从早期简单的单机应用，到后来的分布式系统设计，再到现在的大规模分布式系统，软件发展的历程已经演变成了一个复杂的过程，这个过程中有许多因素影响着软件开发的效率和质量。
为了应对这些问题，一种先进的软件开发架构逐渐走进人们的视野，它就是面向服务架构( Service-Oriented Architecture, SOA)。
面向服务架构是一种软件架构的风格，它的关注点不是单个应用程序或系统，而是由一个或多个服务组成的网络，这些服务通过相互协作，能够完成特定的业务功能。
服务作为功能的基本组成单元，对外提供标准化的接口描述和契约，方便其他服务以标准化方式进行访问和使用。
SOA从多个服务组成应用的角度来看待应用系统，它强调组件的重用性、模块化、松耦合、构建可靠可用的应用系统。
SOA的具体实现可以通过使用Web服务技术来实现。
Web服务是一种标准化的服务组件，可以通过网络进行通信，通过SOAP协议进行数据交互，并通过WSDL文件来描述服务接口和数据格式。
Web服务可以在分布式环境中实现服务发布、发现、组合和集成，简化了分布式系统的构建和管理。
SOA可以带来很多优点，例如：1.灵活性和可维护性：由于SOA组件的松耦合关系，因此我们可以只更改一些特定的组件以实现所需的更改，而不影响其他组件的运作。
2.可重用性：IS组件（Integration Service）和SOA架构是基于组件化的原理，使得组件可重用和跨系统、跨平台使用，可降低开发成本。
3.易于管理：SOA元素尽可能地作为单独的部分运行，这使得管理它们变得更加简单。
此外，服务元素可以像LEGO一样连接在一起，以实现所需的各种功能模块的复杂组合。
4.提高互操作性：SOA支持通用标准和协议，这使得基于SOA技术的系统可以与其他技术平台和系统进行互操作，从而进一步加强组织间的互相连通性和互动性。
5.提高应用程序的可扩展性：SOA使应用程序组件化，从而易于扩展和调整。
通俗地理解⾯向服务的架构（SOA）以及微服务之间的关系SOA是⼀种软件的应⽤架构⽅法，它基于⾯向对象，但⼜不是⾯向对象，整体上是⾯向服务的架构。
SOA由精确的服务定义、松散的构件服务组成，以及业务流程调⽤等多个⽅⾯形成的⼀整套架构⽅法。
这话是不是听起来，让⼈觉得有点晕，我们就细细品读⼀下。
SOA的架构思想（⼀）SOA架构是⾯向服务的，只不过是基于⾯向对象SOA继承了很多⾯向对象的特点，⽐如说⾯向对象的封装，经常代表很多类封装成⼀个模块，为其他对象调⽤者提供接⼝调⽤，良好的⾯向对象设计就是暴露接⼝，隐藏实现，类⽐到SOA的设计，SOA也需要精准明确地定义好服务接⼝，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很⼤的区别：（1）⾯向对象的实现都是基于同⼀个编程语⾔或平台（同构），但SOA服务彻底隐藏了实现上⽤何种语⾔平台的具体细节（异构）（2）⾯向对象的实现其实⼤部分都是本地⽅法之间的调⽤，当然也具备分布式远程⽅法调⽤，但SOA是纯粹提供了独⽴的服务，⾯向分布式的远程服务调⽤。
（⼆）SOA的服务定义是精确的这个怎么理解呢？因为SOA的服务⼀旦发布出来，那么就会有很多其他的异构平台服务进⾏调⽤，这时候的服务接⼝修改就不像⼀个⼈或者⼀个⼩团队之间协作那么容易了，可能涉及到⼀个⼤型企业多部门的信息协作，或者对构件已经形成依赖的⽣态链条。
因此这就牵扯出了SOA另外⼀个特征，那就是服务接⼝的粒度⼀般要设置得⽐较粗。
若提供过多的服务接⼝，服务⼜定义得很细粒度，那么频繁修改是在所难免的。
这⼀点上就注定了SOA架构适合在较重量的环境下存在。
那什么是较重量的环境呢？（1）体系健全、制度稳定的重管理型企业，（2）业务逻辑复杂，服务的独⽴性，开放性需求⼜⼤，服务的稳定性也是刚需。
例如：医院信息化系统架构。
（三）SOA是由松散的构件服务组成为什么是松散的呢？由上述我们可以了解到SOA的服务接⼝是粗粒度的，⽽且组成服务的构件都是独⽴部署并具有独⽴的上下⽂环境，这种形态就是为了降低与其他构件之间的强依赖性。
面向服务的架构标准领先技术不意味厂商锁定XML和Web服务正在作为面向服务的架构(SOA)的平台来出现，它既可用于企业内部通信，也可用于企业间通信。
作为第一个既支持SOA编写，也支持SOA 利用的Java集成开发环境(IDE)，WebLogic Workshop天生就带上了专有创新的印记。
从那时起，BEA通过多种机制，从开放标准到开放源代码，已经实现了对这些创新进行投资保护的承诺，使得开发人员可以充分利用BEA的尖端生产率和集成特性，而不必担心锁定在某一厂商。
下面，让我们一起来看看在Workshop中基于SOA的关键创新，以及在每种情况下是如何保护投资的。
什么是SOA?XML和Web服务是当今的热门技术，因为它们在实现面向服务的架构(SOA)上担当了重要的角色。
目前独立的、而且通常是相互孤立的应用程序，制约了业务服务的共享，SOA则正在解决这一问题。
通过给单个业务操作进行定义或在表层加上“服务访问点”，IT组织能够：•使IT资源与其业务功能更密切地结合在一起•通过以下方法的最佳组合和匹配，建立更加动态、更有效地利用成本的系统•购买和自建•自制和外包•更迅速地发布“组合”应用程序(想想“Web流(Web flows)”和“工作流(work flows)”)，提供统一的、面向任务的跨业务视图•通过更加细致的增量管理需求和变化，在应用程序生命周期上获得更高的灵活性•用提供“业务透明性”的基础架构替换不透明的、“黑盒子”系统更容易—这种基础架构根据流经应用程序的总体信息，提供实时的业务智能。
对象和组件已经成功地在应用内提供了重用性(应用程序的定义是：以单元形式开发和部署的代码)。
但是，SOA依赖的是在应用程序之间实现重用。
用SOA把不同的应用程序互连起来，这根本不是什么新东西—想想以前定义分布式的、应用间通信架构的一些努力(不用费力想什么新的首字母缩略词)：•同步的(面向RPC)：CICS分布式程序链接(DPL)、分布式计算环境(DCE)、分布式组件对象模型(DCOM)、公共对象请求代理体系结构(CORBA)IIOP、Java 远程方法调用(RMI)、关系数据库管理系统(RDBMS)存储过程，等等。
浅析面向服务(SOA)技术的设计应用作者：叶麟来源：《电脑知识与技术》2010年第17期摘要:文章以基于SOA的协同商务平台技术,设计了百分协同商务管理系统。
从总体架构,系统功能和服务组合设计三个方面进行设计,并在服务设计方面对信息流管理,资金流管理,物流管理三块服务利用BPEL4WS设计了相关的服务,通过服务的变化和构件组合来应用了基于服务SOA的架构技术。
关键词:SOA;协同商务;服务设计;BPEL4WS中图分类号:TP393文献标识码:A文章编号:1009-3044(2010)17-4682-04Service-oriented Architecture Technology Design and ApplicationYE Lin(Rieke Packaging Systems(HangZhou) Co., Ltd., Hangzhou 310018, China)Abstract: This article has design the BAIFEN Collaborative Commerce platform base on the SOA technology. It analysis from three section, include main framework, system function and service design .Also when talk about the service combined design. It aim at information,finance and logistics management. Through the service changed and component used that show the SOA application technology.Key words: SOA; collaborative commerce; service design; BPEL4WS随着企业信息化的不断发展,企业或多或少的都建立了自己的信息化应用平台,这些平台的应用日益增多,对系统的应用要求也越来越大,SOA作为一种新的架构思想和技术为企业信息化平台的整合,带来了许多发展机会[1]。
SOA 面向效劳的体系构造面向效劳的体系构造〔Service-Oriented Architecture，SOA〕是一个组件模型，它将应用程序的不同功能单元〔称为效劳〕通过这些效劳之间定义良好的接口和契约联系起来。
接口是采用中立的方式进展定义的，它应该独立于实现效劳的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的效劳可以一种统一和通用的方式进展交互。
这种具有中立的接口定义〔没有强制绑定到特定的实现上〕的特征称为效劳之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个效劳的内部构造和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和构造是严密相连的，因而当需要对局部或整个应用程序进展某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比方经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需〔On demand〕业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进展必要的更改。
虽然面向效劳的体系构造不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA 的系统并不排除使用面向对象的设计来构建单个效劳，但是其整体设计却是面向效劳的。
由于它考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA 系统原型的一个典型例子是通用对象请求代理体系构造〔mon Object Request Broker Architecture，CORBA〕，它已经出现很长时间了，其定义的概念与SOA 相似。
然而，现在的SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言〔eXtensible Markup Language，XML〕为根底的。
面向构件的中间件[EOS产品白皮书]SOA从面向构件开始目录要点 (3)1.变化和可控的挑战 (3)2.SOA从面向构件开始 (5)2.1.SOA的本质 (5)2.2.中国SOA需求呈现和美国不一样的特点 (6)2.3.面向构件是构建SOA服务的最佳方式 (7)2.4.面向构件与SOA (7)3.面向构件技术体系 (8)3.1.软件技术发展的4个阶段 (8)3.2.什么是面向构件？ (10)3.3.面向构件的核心特征 (11)3.4.面向构件的应用 (12)4.面向构件的中间件-EOS产品组成 (12)4.1.EOS产品概述 (12)4.2.EOS集成开发环境 (15)4.3.EOS构件运行环境 (17)4.4.EOS管理控制台 (18)4.5.EOS基础构件库 (20)4.6.EOS工作流(选件) (21)4.7.EOS富页面控件(选件) (22)4.8.EOS报表(选件) (24)5.EOS特点与优势 (24)5.1.EOS构件运行环境（EOS Server） (24)5.2.EOS集成开发环境（EOS Studio） (25)5.3.EOS管理控制台（EOS Manager） (26)5.4.EOS基础构件库（EOS Foundation Component Library） (26)5.5.EOS工作流（EOS Workflow） (26)5.6.EOS报表（EOS Report） (27)5.7.EOS富页面控件（EOS RichWeb） (28)6.EOS应用价值 (29)7.典型用户 (30)8.业界评价 (32)关于goCom社区 (34)关于普元软件 (34)要点Ÿ中国企业如何使得IT系统快速适应业务需求的变化，以及如何更好地对IT系统建设实施管理和控制，是当前企业建设IT系统面临的主要挑战Ÿ中国实施SOA的关键任务是大量的SOA服务需要基于新的业务需求进行构造，而面向构件技术是构建SOA服务的最佳方式Ÿ面向构件技术体系的3个核心特征：全流程管理、无缝访问各层资源、易于根据需求而改变Ÿ从应用开发的层次看，面向构件技术是SOA中“服务”的组装和实现Ÿ普元EOS是基于J2EE平台、采用面向构件技术体系实现企业级应用开发、运行、管理、监控、维护的中间件平台ŸEOS给客户带来的核心价值：统一的企业级应用平台、快速响应新的业务需求、系统高度的稳定性、方便的系统维护和监控、保护已有的软件投资、屏蔽技术细节专注业务需求、降低人员流动风险Ÿ普元EOS已经应用在电信、金融、政府、大型企业等行业超过100多家大型客户，支撑着这些客户关键业务系统的运行1.变化和可控的挑战中国市场是目前世界上变化最快、增长最快的市场。
当前中国的企业正面临着前所未有的机遇和挑战，竞争日趋激烈，新的业务和交易渠道不断涌现，企业需要不断地调整战略，相应的IT 应用也需要随之改变以适应新战略的快速部署。
而传统系统不能快速地实现业务的变化。
经常客户发出慨叹“业务的变化速度10 倍于应用系统的变化速度”。
在这样一个不断创新、迅速发展变化的环境中，中国的大量客户，包括电信、金融、政务，本身的业务发展模型、市场定位都在不断的演化过程中，而其信息技术部门往往因而承担着巨大的责任，在整个企业级IT信息系统的规划和建设中面临着一系列艰苦的挑战：挑战一：IT如何快速响应企业的业务和管理需要一方面，中国的发展中的业务模型在全球找不到第二家，也因而找不到另外一个地方的成熟的应用软件可以购买来完成自己的业务，国外规范成熟的套装软件在中国企业大多水土不服。
比如在电信行业，在使用国际计费产品失败之后，寻找集成商或者自主开发成了首选。
然而另一方面，现有的技术体系使得开发能力受到很大限制，代码级的开发方式、紧密耦合的系统结构，使得在开发常常以百万代码计的系统时，需求的变更、开发人员对需求理解的差异、软件开发人员的流失，任何的变化，都可能会带来系统级别的代码“地震”，从而使得整个项目延期、质量低下，难以满足企业对IT系统时间上的迫切需求。
挑战二：如何规划具有良好扩展性的系统在这样一个企业自身需求不断变化而又不能完全提前预知的环境下，必须在业务需求和关键技术上找到一个平衡点，即让IT快起来，当前的需求能够快速满足，新的需求能够在已有系统基础上快速调整并实现出来。
企业自身需求的这种的不稳定，必然要求整个软件系统的结构具有良好的扩展性，否则新需求的实现往往会造成老系统无法承受，只能推倒重来，这不仅会造成新业务的推出时间的延迟，还会造成软件投资本身的极大浪费。
挑战三：在不断变化的环境中保持稳定可靠的系统结构新的需求必须得到满足，然而在代码开发方式下，整个软件体系错综复杂，代码之间的各个参数之间具有连锁关系，变化带来的是一系列的连锁反应和调整。
依靠在已有系统上不断打补丁的方式，使得整个软件系统的质量难以维护，系统的性能脆弱。
而对于电信、金融等服务行业来说，IT系统处在业务的核心地位，系统运行的不稳定以及错误，都可能会给业务的正常开展带来负面的影响。
挑战四：获得自身对IT系统项目的管控能力软件作为用户的核心知识载体之一，能够得到有效监管是非常重要的一个问题。
基于传统的软件定制的方法，不同的集成商、开发商在项目管理方法（包括开发规范）、软件架构和技术方向上差异太大，使得用户难以进行有效监管，而且使得用户严重依赖于开发商。
同时，越是大型应用系统，越需要运行时故障追踪、运行分析、调优等管理工具，而因各种原因，开发商通常很难提供好的监控工具，这使得用户对应用系统本身的运行维护也难以有效管理；挑战五：降低总体拥有成本基于代码方式的软件体系结构，很难进行拆分复用，即使是功能非常类似的模块，在不同的项目中也需要重新开发。
另外，软件的开发成本仅仅是总体成本的一部分，软件上线才意味着一个软件生命的开始。
因为需求的快速变化，二次开发的成本和维护的成本被大大增加，同时，到达软件无法承受的时候只能另外重新开发，这些都造成软件是一个“奢侈品”。
010********管理众多软件系统和供应商适应技术的改造换代控制成本整合或扩展原有系统适应业务需求的不断变更（%） n=50图表 1中国企业在当前IT 应用系统建设中面临的最大挑战，IDC ，2007年3月总而言之，中国企业如何使得IT 系统快速适应业务需求变化，以及如何更好地对IT 系统建设实施管理和控制，是当前企业建设IT 系统面临的主要挑战。
SOA 作为一种软件系统架构方法论应运而生，其主要目的就是帮助企业的业务流程更加灵活，通过让IT 运行环境更好的支持业务的变化，来保证业务的灵活性，SOA 已经成为未来统一的企业级应用架构。
2. SOA 从面向构件开始2.1. SOA 的本质面向服务的架构(SOA)是一种设计方法学，其目的是最大限度地重用应用程序中的“服务”以提高IT 适应性和效率。
虽然这些概念已经存在了数十年之久，但只是在出现了基于标准的集成技术（如Web 服务和XML ）之后，SOA 才开始被加速采用。
SOA 的核心是把组织的业务流程功能模块构件化，并对外提供标准的服务，基于这些服务，组织内部的不同业务部门或是不同组织之间的业务整合更加容易。
从某种意义上讲，SOA 可以被看作是EAI 的一种延续，但不是简单的延续。
EAI 与SOA 同样解决企业集成的问题，但是，EAI 解决集成的问题往往是在事后，碰到了集成问题，才去想办法通过 EAI 来解决，因此EAI 解决集成问题时，可能会带来更多其他集成问题，最终会带来一个更加复杂的IT 架构。
与之相反的是，SOA 架构解决集成的问题是事先的，SOA 架构把被动集成变成了主动服务，依据SOA 架构搭建的应用系统，就自然具有了可集成的能力，这是SOA 区别于EAI 的一个重大不同。
人们在规划系统建设时，往往立足于当前需求做出相对短期的判断，已经建了哪些系统、现在还需要建设哪些系统以及哪些系统需要整合来制定计划。
实际上这是一个误区，即将建设与整合孤立看待。
我们无法对未来的需求作出完整的预测，因此割裂看待建设和整合必将带来系统建设上的“孤岛现象”。
根本的解决之道，我们需要将建设和整合有机统一起来，从设计上就能够充分意识到系统总是在整合一切可以利用的资源（内部的、外部的）的基础上发展起来的，是为了满足新的业务变化需求。
新系统就是旧系统的利用整合，同时它又是将来能够被新业务整合的资源。
构建SOA服务，以及用标准的方法重用与整合服务是SOA的核心任务，是实施SOA的两个方面。
SOA服务的构造可以是对已有系统中的功能进行提取和包装，也可以是基于新的业务需求进行构造。
2.2. 中国SOA需求呈现和美国不一样的特点过去的半个多世纪，美国从主机时代、PC时代，到了现在的网络时代，积累了大量的应用系统，企业信息系统的建设覆盖到企业运作的方方面面，企业业务流程稳定、成熟。
然而，这些应用系统是用各种各样的非标准方法构造的，企业的业务流程大多数以非标准的形式被掩藏在各种各样的应用系统之中，比如CRM系统，ERP系统，HR系统，信用评估系统等等。
在这样一种背景下，美国实施SOA架构的关键任务是：对已有系统中的功能进行提取和包装，形成标准的SOA“服务”，然后借助于企业服务总线（ESB）等手段，把服务按照业务流程需求整合起来。
也即是说，在美国，SOA服务的构造偏重于对已有系统中的功能进行提取和包装。
而在中国，信息化进程只有近20年的时间，整个企业的信息化进程和现状同美国是不一样的。
据国际咨询机构IDC 2007年3-5月针对中国50家中国大中型企业的CIO和IT经理进行的访问，中国企业建设了大量生产型系统，目前正在尝试着整合；而大量的服务性系统仍有待新建。
调查发现，中国企业更多的在进行系统新建或改造优化。
57.5%的接受调查的中国企业建设重心在系统新建和系统改造、升级；重心在系统整合的企业只占42.5%（见图5）。
对已有系统的改造优化主要是系统升级、新建功能模块或新开发周边系统并集成到已有系统。
在金融、电信等行业，大客户已经建设了近90%的生产性系统，但与国外同类企业不同的是，它们仍然缺乏大量的服务性系统；超过70%的服务不存在或需要重新构造，比如CRM等才刚刚开始。
因此，大量的SOA服务需要基于新的业务需求进行构造，遵从SOA“建设即集成”的理念，从建设开始即遵循SOA架构，才是中国SOA的主要任务，这一点和美国是完全不同的。
对已有系统改造为主已有系整合或改造同时进行. (52.5%)以新建系统为主(5.0%)n=50图表 2 IDC 中国企业SOA 应用调查，2007年3月2.3. 面向构件是构建SOA 服务的最佳方式构建SOA 服务，可以采用包括纯代码编写、基于套装软件二次开发等手段，但是在中国这样一个业务需求不断发展变化的环境下，SOA 服务本身也必将是不稳定的，需要不断的优化、调整、改进。
