编译文章——理解面向服务的IT架构（三）（By AMT 张纯棣）

理解面向服务的IT架构（三）

David Sprott与Lawrence Wilks

CBDI Forum

2004年1月

编译 AMT 张纯棣

关系重大的流程

正如早期所暗示的那样，CBDI认为，好的SOA都是形势和风格上的——包括策略、实践和框架等。这使得流程成为整个项目成功的核心，也是必须思考的一个因素。

同时，组织可能通过使用组件来实现某些服务的利益，而且也很少有组织会严格的强迫流程的提供和消费分离。由于接口协议都采用了统一的标准，这使得服务变得更加容易，但我们需要认识到，这一分离是需要管理的。例如，我们很容易将服务流程的建立和消费分开，但如果消费者和服务的改进都是由同一团队进行，那我们就会很容易的测试服务，看其是否反映了我们对客户潜在需求的理解。

SOA强调，实施流程时一定要确保至少存在两个相互分离且不同的流程——为服务提供者和服务消费者。

然而，当前用户对于无缝的端对端业务流程需求，其实是使用Web服务的一个关键驱动因素，它意味着，组织内的服务提供者和消费者之间总会存在着很清晰的分离，而且在潜在意义上说，每一方之间多对多的关心都有许多不同的目标，但无论如何，所有参与方都需要使用同样的服务。我们的建议是，所有的开发组织都应该这样行动，即便当全部的提供和消费流程都是内部完成时，开发团队也要保证所设计的服务要与未来需求相一致。

对于消费者来说，流程必须按照服务接口的需要来组织，并且要保证不需要依赖任何服务实施有关的知识。如果这一点可以实现，由灵活性所带来的相当可观的利益自然会增加，因为服务设计者不能对消费者行为作出任何假设。他们必须提供规范的、且带有客户可以承受范围内奖金的合同，服务消费者的开发人员只需要知道服务在哪里，他们都做什么，他们如何使用这些服务就可以。接口是真正与客户接触的部分，因为它定义了服务之间是如何实现交互的。

同样的，在服务提供商有一系列不同的顾虑的时候，我们需要开发并交付一个完全可以被服务消费者独立使用的流程。服务提供商的注意力再一次的集中到了接口上——接口的描述和合同。

另一个思考方式就是看服务的提供者和消费者之间合作的性质。起初，你可能认为，在实施和服务提供与服务消费之间有着明确的划分，实施和服务提供由服务提供者所有，而消费则由消费者所有。然而，如果我们从合作的角度来考虑这些最高级别的流程，那么我们就会看到一幅截然不同的图画。

我们拥有着大量领域的流程，在各个领域中（根据服务的性质不同而不同），我们可以发现在服务提供者和服务消费者间存在着很深的协作关系。从潜在意义上来讲，我们对软件交付流程进行了主要的工程再造工作。尽管我们在基于服务的流程上存在着两个主要参与方，我们把需要管理的领域归结为三个主要流程。当然，这需要一定的分解，但下面的几个方面似乎是主要的最高级别流程：

¨          支付服务实施的流程

?            传统开发

?            编程

?            Web服务自动化

¨          服务的提供——服务的生命周期作为一个可用的方面

?            面向商务

?            内部和外部视图

?            服务级别管理

¨          消费流程

?            业务流程驱动

?            服务消费者可以是内部也可以是外部的

?            从服务角度来组合解决方案，而不是单纯的代码

?            增加图示化的开放方法

?            可以用业务分析师或者只是工作者来承担

采用这一视图的优势在于，流程的协作方面主要都包含在流程提供领域内。而提供领域是非常重要的，因为协议的性质会对流程需求产生很大的影响。在设计消费者/服务提供者合作时，主要有两种可供考虑的形式：

¨          商议的——消费者和服务提供者联合达成服务协议。当新的服务被开发出来后，服务提供方和消费方应有机会进行商议，达成关于服务如何工作、服务的内容是什么等等方面的协议。在行业内，有很多参与者都互相进行着交易，同时服务对于大部分的提供方来说是一样的，因此，对于整个行业来说，考虑标准化这些服务是非常必要的。这样的例子包括：

?            早期的采纳者

?            新的服务

?            密切联系的合作伙伴

?            行业领导者——形成规范

?            内部使用

¨          例示——就是这样的。要么接受，否则离开。合作环境下的一方可能对服务进行一系列的强制性规定。有时，服务已经存在，你仅仅是选择是否使用它而已。这样的例子包括：

?            占优势的合作伙伴

?            服务提供者领导——必须使用这一服务，否则我不可能提供服务

?            消费者领导——必须提供这一服务，否则我们不可能进行我们的业务

?            行业领导者——标准合约

?            现有系统/接口

架构

这一流程认为，在考虑需求架构的类型、利益范围，责任和完整性时，上述我们需要检测的内容都是必须的前提条件。对SOA来说，有三个主要的架构视角需要考虑，见图1：

图1：三维架构视角

¨          应用架构：这是面向业务的解决方案，从一个或多个服务供应商那里消耗服务，并将他们集成到业务流程中。

¨          服务架构：这一架构视角提供了实施和消费应用、创建可用服务集的逻辑试图的桥梁，所有可yon服务都受到通用接口和管理架构的调用

¨          组件架构：这一架构视角描述了支持已实施的应用和业务目标等的各种环境。

这些架构既可以从消费者的角度，也可以从服务提供者的角度来看。架构的关键点在于，服务的消费者不应该对于服务实施的细节过分关心——仅仅对提供的服务感兴趣就可以。尽管实施架构可能会根据服务提供者的不同而不同，但他们仍可能提供同样的服务。同样，服务提供者也不应该对于服务所使用的应用过多的关心。新的不可预见的应用都将可能在同一服务集中被重用。

消费者关注于他们的应用架构，使用的服务，但不是组件架构的细节信心。他们更关心符合双方共同利益业务目标中的某些级别的细节信心，例如，服务提供者和消费者需要共享一个关于订单的试图。但消费者并不需要知道这些订单组件和数据库是如何被实施的。

同样的，服务提供者关注于组件架构，服务架构，但不关注应用架构。在一次的，他们都需要了解某些关于基础应用的共同信息，例如为了设置各种顺序规则和事前、事后条件等。但服务提供者不会对非常详细的消费应有信息感兴趣。

2410字