经过40多年的发展，IT系统迅速普及，同时其架构也日益复杂，这给软件系统的使用和维护带来了挑战。传统的软件架构已经接近其能力的极限，而企业仍然还在不断提出各种新的软件需求。IT部门还需要快速响应新的业务需求、不断降低IT成本，同时实现与新的业务伙伴和客户的集成。从软件产业本身来说，为了适应新的需求，也做出了很多努力。比如，为了支持完全的分布式业务流程，推出了多种软件架构；为了保证软件能在各种平台上运行，而特别设计了各种编程语言，然而直到SOA的出现，人们似乎一直看不到问题会解决的希望。现在，作为一种帮助IT部门应对日益复杂的挑战的革命性技术，面向服务的软件架构（SOA）正在被越来越多的软件人士接收。
IT系统的集成已经成为全球大小企业IT部门共同面对的问题。集成的困难在于太多的软件平台、太多的对象模型（比如，与CORBA不兼容），结果，很多架构设计师和软件工程师被深陷于解决这些技术难题之中，他们要设计一种稳定的、能简单、快速、安全地与现有系统和应用进行集成的架构。然而，不幸的是，直到SOA出现，这个问题一直没有解决，而且愈演愈烈。满足业务需求这个最实在的需求促使人们寻求一个更好的解决的办法：一种能降低成本、缩短开发周期、实现企业内部集成、与B2B和B2C系统的集成、更快地获得投资回报、能快速灵活地响应业务需求的软件架构。人们的反复实践表明，点对点的办法不能满足要求，因为这种方式没有一种统一的架构，使得软件开发人员能快速开发、集成和重用应用。更为重要的是，我们需要一种软件框架，能在业务发生变化之后，动态响应新的需求，快速重新装配各种软件构件和服务。本文重点将不是论述为什么某些技术，如Web服务非常有用，而是超越技术层面，从架构这个角度来讨论这些问题。
企业的软件之痛
这里首先从讨论软件所面临的一些最基本的困难开始，要注意的是，我们考虑如何解决这些困难将决定我们成功的程度。
* 困难一：复杂性
业务部门所遇到的困难几乎IT部门都会遇到。企业管理者希望更充分地利用IT资源、更快地得到投资回报、和现存的系统进行整合、快速地部署新的系统。但有些事情正在发生变化，软件运行环境日益复杂，IT预算日益紧张，再加上部署时间紧张，要求我们尽量重用旧的系统，而不是取代它们。便宜而且方便地接入互联网为开拓全新的业务模式提供了可能，而另一方面，为了跟上竞争对手的步伐，企业也不得不重新审视现有的商业模式。今天，企业并购频频发生，从而使得企业的IT部门常常面临集成企业的IT基础设施和应用的任务。在这样的一种环境中，点对点的解决方案只能增添问题的复杂程度，而远不能真正解决上述困难。现在需要一种新的架构，能充分包容各种异构的计算环境，包括各种不同的硬件、操作系统、中间件、语言和数据源。数十年来，计算机领域不断演进留下的大量系统已经成为我们下一步发展的巨大障碍。考虑IT部门现在遭遇的上述挑战，再看看今天很多CIO将集成列为头等大事就一点儿也不觉得奇怪了。
* 困难2：冗余和难以重用的程序
很多企业的应用系统来自于不断地在并购中集成被并购的企业。因而，企业不得不面对冗余的信息系统或者从功能上说难于重用的应用。在不少企业中，各个业务部门相互独立，从而为企业重用某些功能和系统造成了极大的障碍。这些冗余的系统为企业在部署新的产品和服务时增加了成本，而且延误了时间，因为某个系统中的一个小的改变就会导致在几乎每一个系统或者应用的修改。不能重用最终还会消耗更多的有限资源，在交付新的应用时需要更长的开发和部署时间。
* 困难3：众多的接口
考虑n(n-1)个连接。由于企业的并购或者成立新的企业联盟或者只是为了和现有的系统建立连接，很多企业都面临这方面问题。比如，有n个应用必须直接建立连接和接口，点对点的模式需要建立n(n-1)个连接。在图1中，每一个接口代表一个连接。结果，如果需要连接一个新的应用，那么就必须建立、测试和文档化2n个连接。在图1中，5个应用间就需要20个直接连接，添加第六个应用就需要新建10个直接连接，这会给这些应用的维护带来很大的问题，因为这必须修改每一个现存的应用让他们包含新的接口，相应的测试成本也会成指数级上升。为了降低成本和复杂性，我们需要一种简单的解决办法：如果有n个应用就只需n个接口，新增一个应用也只是新增一个接口。然而，采用直接的点对点的连接是无法满足这一要求的。
理想的软件
过去的40多年里，软件开发领域经历了几个不同的编程模型。每次转变都在一定程度上降低了软件系统的复杂性，使得软件人员能在一定程度上更方便地组装不同的应用、构件和服务。几年前出现的Java技术提供了一种与平台无关的编程特性，XML为数据提供了一种自我描述、跨平台的表现形式，而现在的Web服务则帮人们搬掉了另外一个障碍，允许各种应用之间实现互通。例如，只要遵循基于XML的简单消息规范，Java应用就可以调用微软的.Net的应用或者与CORBA兼容的应用，甚至可以是COBOL应用。因此，位于新加坡大型机上的IBM CICS或者IBM IMS交易可以被.Net应用调用，而这个.Net应用则是被慕尼黑的Lotus服务器应用调用的。最值得一提的是，在进行调用的时候，发起调用的一方根本就不用关心交易究竟在哪里完成、这个程序是用什么编程语言编写的，以及消息会经历什么样的路由过程。整个过程只是一方申请服务，而另一方提供这个服务这么简单。
相对而言，Web服务由于效率更高、更可靠、更可扩展，因而将比它的前辈更可能被作为一种机器与机器进行交互的事实标准。而几个必要的技术的即时融合以及文化上的即时跟进更是加快了这个过程，包括：
* 随处可得的基于开放标准、低成本的网络基础设施以及支持分布式环境的有关技术使得Web服务比CORBA和DCE（分布式计算环境）更有可能被作为标准。
* 在那些为了达到关键业务目标必须实现交互的网络环境中（如分布式协作）的接受程度和技术成熟程队。
* 人们希望基于开放的互联网标准和技术实现低成本的交互。
* 网络技术（如TCP/IP）的成熟程度。
* 集成开发环境（IDE）、统一建模语言平台（如J2EE）及其他有关的技术（如面向对象技术和服务）可以非常容易地实现机器与机器的松耦合交互，这是CORBA用户很难有的一种经历。
SOA既是一种软件架构，也是一种编程模式，还是一种思考部署软件的方法。SOA使我们能设计一种软件系统，它能通过公开发布的或者可发现的接口为其他应用提供服务，这些服务可以通过网络被其他应用调用。人们使用Web技术实现一个SOA应用时，就可以得到一种新的软件构建方式，这种方式十分灵活、威力强大，而且能够降低开发成本和拥有成本，减少系统实施风险。
另一方面，对于SOA来说，目前正面临着很大的机遇。第一个是网格计算。今天，网格计算已经不是每秒完成数百万条指令的一种应用，它能够提供一种框架，使我们能动态分配、再分配、平衡和管理大量的服务，它能保证我们得到所需要的服务而无论这个任务是不是由自己的机器来完成。
按需计算与网格的概念非常相似，它能在任何配置的机器上实现，从简单的集群到1024个节点的运行IBM SP系统的网络。如果用户为了解决某个问题而需要计算能力，无论多少，他可以根据实际使用的计算能力付费。为了达到这一目标，需要对现有软件系统进行重构。现在的单片集成电路可以在这个环境中运行，但是远不是以一种最佳的使用方式使用。这些情形以及前面所述的问题意味着我们必须对软件系统进行一个彻底的改变，也就是要向SOA转变。
对SOA的需求
根据前面的论述，SOA的重要逐渐清晰起来，显而易见，开发一种能满足我们所有需求的软件架构非常重要。这些需求包括：
1. 利用已有的数字资产
这是最主要的需求。现存的软件系统很少是能够丢弃不用，在这些系统中很可能含有对企业而言非常有价值的数据。就战略而言，目标是建立一个能满足当今所有需求的新的软件架构，就战术而言，必须对现有的系统进行集成，逐步把它们组件化或者替换。
2. 支持各种类型的集成
包括与用户的交互（提供单一的、可交互的用户体验）、与应用的连接（在现有的架构上增加一层通信层）、业务流程的集成（包括服务和应用的集成）、信息的集成（实现企业的全部数据的集中管理和控制）、整体部署（建立和部署新的应用和服务）。
3. 允许系统的逐步实现和迁移
要满足这一需求，软件架构必须具有非常关键的一个特性：能逐渐实现投资回报。无数集成项目最终失败，其原因就在于这些项目过于复杂、成本太高、或者实施计划无法执行。
4. 建立一个标准化的构件框架
这需要一个开发环境，在这个环境中可以建立一个标准的构件框架，从而更好地重用模块和系统，同时，还允许老系统迁移到这个框架中和及时地采用新的技术。
5.允许实现新的计算模型
这些新计算模型包括：支持新的便携式客户端、网格计算和按需计算等。
Web服务
Web服务的实现给软件基础架构的开发、部署和管理带来了根本性的改变。很多Web服务项目的成功已经表明Web服务这种技术的确能够帮助人们实现真正的SOA。Web服务让人们在关注基本的业务问题的同时，能以一种新的方式重新审视他们的应用架构。从业务的角度来说，这不仅仅是技术问题，而是要开发一种应用的架构和框架，在这种框架中，人们能够以一种一致的、可替代的方式定义业务问题并找到解决办法。
然而，首先要认识到Web服务并不等同于SOA。Web服务是一组相关技术的集合，包括XML、简单对象访问协议（SOAP）、Web服务描述语言（WSDL）和统一描述、发现和集成（UDDI），这些技术能够帮助人们针对具体的消息和应用找到编程的方法。假以时日，这些技术还将更加成熟。虽然他们最终会被更好、更有效率、更稳定的技术代替，但目前已有的这些技术已经足够了，而且今天已经证明人们能够用这些技术实现SOA。
SOA的本质是什么？正如SOA的名称所表示出的含义，SOA是一种架构，它不仅仅是某种技术，例如Web服务。它是超越具体技术的，最理想的情况下，SOA是与技术无关的。在商业环境中，一个纯SOA的架构可能是这样一个应用架构：其中每一个功能都被定义为独立的服务，它们都具有良好定义的调用接口，可以按照业务流程需要的顺利被依次调用。以下内容是SOA的核心：
* 所有功能都被定义为服务，包括较高层次的业务功能（例如，一个贷款申请或者发出一个订单），以及更低一级功能实现的交易（如取得信用记录）和系统服务功能（如身份验证或者用户相关信息）。这就带来了功能划分粒度的问题，后面会解决它。
* 所有的服务相互独立的，它们像“黑盒子”一样，外部的构件根本不知道也不用关心它们的功能是如何完成的，只要能取得所需要的结果就足够了。
* 接口是可调用的，即：在架构层次上，无论服务位于本地（在系统内）还是在远端（系统外）都不影响调用，服务内部是如何实现的也不用关心。服务可能是在同一个系统中，也可能在一个不对称多处理器的另一个地址空间中，甚至可能位于企业内部网中一个完全不同的系统中，还可能位于通过B2B连接的合作伙伴的系统中。
在SOA架构中，接口是关键，在调用应用时这是关注重点。它定义了所需的参数和返回的结果的结构。这就意味着它定义了服务的本质，而不是具体使用哪种技术来实现。系统必须实现和管理服务的调用，而不是执行调用的应用。这个特点可以实现两个最关键的特性：首先，服务是真正独立的；其次，它们是可管理的。可管理有很多作用：
* 在安全方面：验证请求，在需要时加密和解密数据，确认信息的有效性；
* 在部署方面：为了优化性能或者减少冗余，允许网络中的服务位置动态变化；
* 在登录方面：提供审计和评估能力；
* 在动态路由方面：提供失败恢复和负载均衡能力；
* 在维护方面：管理服务的最新版本。
| 共2页: 1 [2] 下一页 |
