dev2dev 首页 > 资源中心 > 技术文章
SOA：在最初就让它正确
 现在构建一个成功的服务架构并不意味着您是正确地构建了它
构建一个面向服务的架构（SOA）很容易。大多数标准都经过了严格定义，开发人员只需很少的新技能就可实现服务组件，并且可以使用现有的语言和开发工具。当然，因为这是一种新方法，所以现有的技能必须要适应
Web 服务原本的设计使用意图，但这将随着时间的推移而发生。实现SOA的技术途径看起来（如果不是完全顺畅的）至少是可行的。
这是一个好消息，因为企业SOA的潜在优势是非常引人注目的。这些服务可由多个应用程序来使用，且并可用于未来的应用程序，从而加速新应用程序到达用户手中的过程。服务可以使企业更灵活，并为响应业务或竞争环境中的改变做好充足的准备。
但是，构建一个SOA并不仅仅是编写代码和构建软件模块。实际上，多数企业都极有可能将其搞错并且从中得不到什么好处。此外，随着维护和增强这些服务的复杂度增加，以及利用这些服务的应用程序占用越来越多的资源，将其搞错将很可能导致效率降低并增加成本。这样，您会认为一个瘦的、灵活的SOA可以变成一个不可能支持和增强的、难以使用的代码沼泽。
技术是容易的部分
问题不是构建Web服务本身，总的来说而是SOA的架构。与多数架构不同，SOA的架构更多的是业务的挑战而不是技术上的挑战。多数SOA无法实现其预期目标的原因是他们不能将其关联到业务目标。
您可能认为构建SOA主要涉及到快速和高效的服务、最低限度的服务接口、优化的数据库访问和足够的网络带宽以及处理能力。关于SOA是否具有实现价值的能力，这些当然是架构考虑的一部分。但是这些是技术问题，易于考虑和解决。实际上，在理想情况中这些技术问题应该在实现SOA前就计划好了，在构建架构期间就可以成功地解决这些问题，甚至可以在使用中解决。换句话说，正确处理好这些问题只是刚把您领进门，但离成功可能还很远。
但是其他的SOA架构问题就是基础设施部分了，并且这部分不能在架构实现后再修补。在服务定义方面的工作可比服务的实现要多。换句话说，您可以构建完美的服务，除非它们可能不是能给您的组织带来好处的服务。
以这种方式想一想：服务定义了一个组织的关键业务实践，应用程序则调用这些服务来完成这些实践。例如，一种这样的实践可能是定购产品。您可能会说所有的企业都以相同的方式来进行这项工作，但关于它是如何实现的总还是有一些独特的地方。在本例中，一个访问者到网站选择一件物品，此时Web服务检查存货数据库，以查看该物品是否有现货。如果有现货，该Web服务会调用另一个服务，此服务准备定价和交货信息。结果会送回第一项Web服务处，并将可供货性、定价和交货信息交付到用户。
模拟手动过程的Web服务集已经在企业中存在许多年了。但这样就存在一个问题，那就是在未来的某个时间，企业会改变这种特定的实践。现在有不同的发运方式了，并且用户为了完成交易就必须选择一种发运方式。但是在业务实践中现有的Web服务无法轻松地支持那种改变。在最低限度上，很清楚应用程序将不得不独立地调用第二个服务，而不是由第一个服务调用。在最糟糕的情况下，为了支持业务实践中的单个修改，可能必须部分或全部重写两个服务。
这个特殊的示例有些虚假和过于简单。任何现实中的类似情况将会更复杂和更难以解决，并且很可能不会存在一个很明显且高效的解决方案。换句话说，这个例子是您将在架构很差的SOA中所遇到的最容易的问题。
这样就提出了一个任何着手SOA策略的人要注意的问题。构建服务，即使是计算高效的服务也不是成功的保证，至少在提供当前和未来业务前景方面不会成功。而这实际上就是关键，没有理由要求一个SOA策略现在就去改进运营，SOA的重要性在于其使您为将来做好准备的能力。
步入一个灵活的SOA
那么如何才能构建一个实现业务以及技术目标的SOA呢？这很难，因为业务和技术目标可能具有冲突点。例如，当今的企业可以依赖于诸如电子数据交换（EDI）这样的技术，EDI具有25年的历史，是在相同行业中的公司间交换格式化文本数据的过程。EDI维护困难并耗费时间，但是将企业迁移到SOA也需要大量的资源。当目前的现实情况干扰了未来的计划时，通常会使那些未来的计划变成次要。人们会在维护现有EDI技术时扩展资源，而不是构建在未来很好地服务企业的架构。
那些在EDI中的投资可能使您不愿意实施向SOA的转换，即便SOA是正在向前发展的正确的业务解决方案。问题在于EDI解决方案已经得到多年实践的证明，而SOA只是表现了无法证明的承诺而已。
您可以采取多个步骤来使得您的SOA有效地服务于现在和未来的需求变得更加可能。没有严格的规则，并且这个策略可能要花费多年才能实现，但这要比构建单个的服务并希望SOA能在该过程中自己建立起来要好。
首先要了解Web服务和SOA背后的技术。这是很重要的，因为您将不可避免地要在可能和实际间作出折衷。知道SOA背后的技术基础，以及如何在您的基础设施环境中应用它们是可以成功实现任何设计的根本。
但是了解业务更重要。这就意味着不仅要有组织做什么和如何做的抽象视图，还要有特定业务实践的直接经验。业务实践的直接经验可为您提供这些实践各部分的分解视图和应用程序如何支持他们的视图。通过了解细节，在容易地支持这些实践的粒度级别上，您就具有了设计服务所需的信息。
如果您具有这些经验，在设计SOA上您就占据了有利的位置，但这仍旧不能保证成功。您必须能够在当前业务实践和未来它所要迁移到的地方之间架起桥梁。"水晶球"在这里可能会有帮助，但遗憾的是没有一个是可靠的。相反，逐渐地移动到SOA中，一次构建一个服务则显得更有意义。尽管这可能看起来与架构的概念背道而驰，但是如果其结果表明最初的计划是有缺陷的，那么这样做就能使您随着时间的推移而采取正确的行动。
因此，下一步是实现一个或两个高价值的服务，这两个服务要能满足重要的直接需求和预期的未来的架构要求。下面是技术开始作用位置的具体细节，随着这些初始服务的技术和业务上的成功，将会极大地推动向总体SOA的发展。
完成一个或两个服务并将其投入生产后，应收集有关它们满足现有需求方面的数据。同时，检验要构建可能使用这些服务的应用程序的需求。如果这些服务无需修改就可用在这些应用程序环境中，那么可能您的SOA就走上正轨了。
如果这些服务不能用于在不久的将来承诺要构建的应用程序中，那么就说明这是您要重新思考您的SOA架构的时候了。您可能将Web服务的粒度定义得太细而无法支持新的应用程序，或者您是依据特定应用程序现今是如何工作的来作出假定。无论哪种情况，您的SOA在快速构建新的应用程序方面未必有用。
从这些最初的Web服务是如何支持未来应用程序的方面来断定它的价值，您可能会争辩这是不公平的，特别是这些应用程序将很快按计划来构建。那些服务可能不适合于这些应用程序，或者服务受限于排除其直接重用的基础设施考虑。我同意这些争辩，但重要的是，您已经以某种方式构建了错误的服务。
这些服务在设计和实现时就已经考虑了当今的应用程序和限制。确实会偶尔有一个或两个最初服务可能无法立即支持未来的应用程序。但是一个良好组织的SOA应该在几乎任何应用程序（现在的和将来的）中能够使用多个服务。如果您不能立即使用新的服务，几乎没有什么有效的借口。
一旦您已经对SOA验证了您的方法，或者根据最初服务的反馈采取了正确的行动，那么您可以通过构建剩余的服务来完成架构。这个过程将可能持续数年的时间，但是这次应该清楚为了支持业务实践而需要什么服务。
将SOA与策略规划结合
为什么正确地将SOA方法应用于应用程序设计会如此之难？这需要构建一组组件，这些组件不仅对当今的业务实践建模，还要具有足够的功能以提供对未来未知业务实践的支持。实际上，一个设计良好的SOA只在进行改变的时间到来时才使得那些未来过程的创建变得明显。
创建成功的SOA的关键，是能够估计业务实践在未来数年内是什么样。很清楚，部分是猜测，所以窍门是根据您的业务知识来猜测。您必须要考虑的事情是组成企业核心的产品或服务混合可能会改变、竞争对手的数量和类型可能会显著不同或者整个业务模型可能会改变。
这种聚焦于未来意味着SOA的构建必须与企业策略规划相结合而完成。由于策略规划过程概括了未来的情况，所以业务和技术架构师则设计将支持这些情形的过程。然后您必须将支持现有业务过程的应用程序组件映射到那些未来的过程中去。这就是SOA组件应该放弃混合的原因。那么您就可以利用架构来继续前行了。在构建实现灵活性的服务和支持新应用程序的能力方面，以及提供实现未来应用程序价值的关键部分方面，遵循这种方法会给您最佳的机会。
另外，简单地使应用程序支持现有的流程并将流程封装到Web服务中可能在纸上看起来很好，并且可能会为创建成功的Web服务赢得赞扬，但是您还没有构建一个能够在未来仍良好地服务组织的架构。
两种方法都可交付企业SOA。后者会导致以后大量出现价值很低或没有价值的服务，并且为了支持新的应用程序而需要开发和维护日益增多的服务。然而，尝试配合企业策略的SOA意味着随着时间的推移只要编写和维护少量的服务。这在初始可能是更大的挑战，但是在未来它的回报会日益增加。
关于作者
Peter Varhol是Compuware Corporation公司的一名高级技术成员。联系Peter：peter@mv.mv.com
| 作者简介 |
|
Peter Varhol是Compuware公司的技术专家. |
作者其它文章
|
