如何解决这一问题？能否来一场软件开发和架构的革命？SOA架构的提出，就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。

    1.定义

    SOA并不是一个新概念，有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在1996年，Gartner Group就已经提出了SOA的预言，不过那个时候仅仅是一个“预言”，当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年，SOA的技术实现手段渐渐成熟了。在BEA、IBM等软件巨头的极力推动下，才得以慢慢风行起来。Gartner为SOA描述的愿景目标是实现实时企业（Real-Time Enterprise）。

    关于SOA，目前尚未有一个统一的、业界广泛接受的定义。一般认为：SOA，面向服务的架构是一个组件模型，它将应用程序的不同功能单元——服务（service），通过服务间定义良好的接口和契约（contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。

    从这个定义中，我们看到下面两点：

    ·软件系统架构： SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。

    ·服务(service)是整个SOA实现的核心。SOA架构的基本元素是服务，SOA 指定一组实体(服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约)，这些实体详细说明了如何提供和消费服务。遵循 SOA 观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。

    2.SOA三种角色的关系

    服务是一个自包含的、无状态(stateless)的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务(transaction)等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。

    服务提供者(service provider)提供符合契约(contract)的服务，并将它们发布到服务代理。服务请求者(service consumer)也叫服务使用者，它发现并调用其他的软件服务来提供商业解决方案。从概念上来说，SOA 本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。

    服务代理者(service broker)作为储存库、电话黄页或票据交换所，产生由服务提供者发布的软件接口。

    这三种 SOA 参与者：服务提供者、服务代理者以及服务请求者通过 3 个基本操作：发布(publish)、查找(find)、绑定(bind)相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务提供者和服务请求者之间可以交互。

    所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态。它们从客户端接受服务请求。因为服务是无状态的，它们可以被编排(orchestrated)和序列化(sequenced)成多个序列 (有时还采用流水线机制) ，以执行商业逻辑。编排指的是序列化服务并提供数据处理逻辑。但不包括数据的展现功能。

    3.SOA特征

    基于上面讨论，我们给出SOA的下面一些特征：

    ·服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。

    ·服务的重用(reuse)。服务的可重用性设计显著地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文(context)中，独立于底层实现和客户需求的变更。

    ·服务的互操作(interoperability)。互操作并不是一个新概念。在CORBA、DCOM、web service中就已经采用互操作技术了。在SOA中，通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。

    ·服务是自治的(Autonomous)功能实体。服务是由组件组成的组合模块，是自包含和模块化的。

    SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

    SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

    ·服务之间的松耦合度(Loosly Coupled)。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使用 API 和文件格式。

    这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码(例如，COBOL)的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的通信协议。

    ·服务是位置透明的(location transparency)。服务是针对业务需求设计的。需要反应需求的变化，即所谓敏捷(agility)设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。

    4.三个抽象级

    从概念上讲，SOA 中有三个主要的抽象级别：

    ·操作：代表单个逻辑工作单元(LUW)的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。

    ·服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度(granularity)大小也与系统的性能息息相关。粒度太小，会增加服务间互操作通讯的开销；粒度太大，又会影响服务面对需求变化的敏捷性。

    ·业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。

    在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。

    三、建立一套行之有效的，在项目启动阶段就应该得到客户认可的需求管理制度

    对变更的内容进行严格的控制实施需求变更管理需要遵循如下原则：

    1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

    2..制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

    3.成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

    4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

    5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

    6.妥善保存变更产生的相关文档。

    需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤：提出变更à变更评估à实施变更。

    需求变更处理流程

    因为现实世界的软件系统可能有不同的严格程度和复杂性，所以事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察，这种新的认识就有可能导致需求变更。CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引人相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪，同时开发工作又不会因此而被扰乱。开发项目应该周期性地暂停来吸收最新的需求变更积累，此时，所有的计划、设计、行为都根据刚刚吸收的需求变更的影响进行更新。

    需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关，比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样，那就是为了使变更管理变得更容易，因此，不论在项目变更控制中采取什么方法、策略，对于项目本身的变化一定要时时洞悉，处处留意，只有这样才能从真正意义上对项目进行很好的变更控制。