内容


基于需求的 SOA 与基于功能的 SOA:确定 SOA 活动的正确焦点

Comments

什么是服务?

服务 是可以独立存在的一段代码。服务通常独立于与其他服务的组合进行标识,并且独立调用执行。因此,服务并不一定是 Web 服务,后者只是服务的一种类型而已。Web 服务是最常用的应用程序服务形式,因为有很多可用于构建此类服务的工具,而且满足服务的所有特征。根据场景和功能的具体情况,也可以将 Common Object Request Broker Architecture (CORBA) 或 Component Object Model (COM) 组件代码指定为服务使用。而且,根据需求(如并发性、可伸缩性、消息交换模式和响应时间)不同,同一个服务可以存在多个对应代码段。服务可以存在于体系结构的所有层次:基础结构层、UI 层和数据层。很多人认为服务只能在中间层中用于完成业务功能,但事实并非如此。

标识您的 SOA 业务驱动因素

每个场景都有为何应该采用 SAO 的独特业务驱动因素。不要仅仅为了开发 SOA 而开发 SOA;应该为了获得通过应用 SOA 作为解决方案能够得到的某些具体业务好处而开始开发 SOA。您应该清楚地确定每个实例的这些业务驱动因素。

还应该从业务驱动因素中确定 SOA 需求。单个产品甚至单个供应商的一套产品并不一定总能满足不同的需求。大部分产品供应商都能满足一组数目有限的需求,但可能不适合每个场景。因此,您 SOA 解决方案的产品供应商选择应该根据 SOA 解决方案的需求确定。另外,不要让产品供应商主导您的 SOA 活动。您的情况和供应商提供的专业方案之间的差异很可能会导致混淆,甚至会导致失败。这可能似乎是个很简单的问题,但行业中因为这个原因导致的 SOA 失败已经让人见惯不惊了。

本文剩下的部分将讨论各种可能的 SOA 需求,以及为了满足这些需求需要关注哪些方面(而不是在未特别考虑其提供的功能的情况下从供应商选择产品)。请将 SOA 功能视为模式,而不是产品。这样可帮助您将重点放在解决方案所需的产品功能上,而且不会被产品功能本身搞得眼花缭乱。有效的 SOA 需要各种各样的功能。避免让已知产品的可用功能主导您的 SOA 活动。这也可能会导致失败。

服务契约

服务契约是帮助确保活动成功的一个重要方面。您必须确定应该在 SOA 活动的服务契约中加以表示的元素,因为不同的 SOA 活动需要不同的特征来确保成功。服务契约是 SOA 活动的基础,因此要谨慎地选择各个特征。接下来我们将对服务契约中可能出现的一些重要信息进行描述。

描述

服务的描述通过服务的功能的详细说明指定。这通常不是计算机能够使用的内容,而是供人使用的信息。

使用者查看服务目录确定特定场景中要调用的服务时,服务描述就非常有用。请注意,此信息不是用于服务的动态绑定,而是用于静态绑定。因此,描述应该尝试介绍不能通过服务的输入和输出参数确定的各个方面。例如,描述可能涉及服务可能产生的所有副作用。还可能会提到与其在事务中使用相关的信息。

服务家谱(pedigree)

服务家谱可帮助确定服务在所提供的所有服务的上下文中的重要性。也就是说,服务家谱根据服务相对于 SOA 解决方案的位置标识服务。这可能会规定服务的部署策略。服务家谱还可以指示服务当前位于测试阶段还是生产阶段。

安全机制

安全机制在标识服务的访问机制过程中至关重要。这可以帮助决定应该使用哪些基础结构服务来绑定和使用此服务。

消息交换模式 (MEP)

服务的消息交换模式是服务提供者和服务使用者为了进行通信而使用的通信模式。服务可以具有很多类型的 MEP:单向、发布-订阅或请求-响应方式。这在选择使用的协议时非常重要。例如,在使用 HL7 协议时,HL7V2.X 可以使用带确认信息的单向消息,而 HL7V3.0 则强制要求使用请求-响应类型的 MEP。

并发性需求

务必确定特定服务预期会有多少个并发执行的调用。实现必须考虑此问题,服务的用户必须就指定的参数达成一致,以免服务出现错误行为。

响应时间

当服务在组合场景中使用,且所得到的服务必须满足一定的服务水平协议(Service Level Agreement,SLA)时,响应时间就非常重要。此指标在独立于 SLA 使用时也非常有用。响应时间可以通过为服务的功能指定的非功能需求(NonFunctional requirement,NFR)派生得到。

支付模型

将 SOA 用于软件作为服务(Software as a Service,SaaS)场景时,由于要向服务使用者收取服务使用费用,因而支付模型就非常重要了。还可以使用支付模型来对货币成本之外的成本形式进行测定。

企业服务总线 (ESB)

ESB 被视为 SOA 活动的中枢。不过,每个场景的 ESB 更改需求有极大的变化。因此,最好首先确定您的需求,然后寻找适合您的需求的 ESB。在某些场景中,一个硬件可以满足 ESB 的需求,很多成功的 SOA 活动都使用此硬件。因此,就像前面提到的,您应该将 ESB 视为满足您 SOA 需求的模式。下面描述了 ESB 产品中需要考虑的一些重要方面。

位置独立性

通常,服务的使用者对提供者的位置并不感兴趣。这样可以根据业务需求更改服务位置,而且不必暂停系统。这通常是 ESB 的重要内容,并且是 ESB 产品应该支持的一个重要方面。

注册中心服务

了解 ESB 产品是否支持将注册中心服务产品与其结合使用非常重要。此服务用于满足确定构建 SOA 时要绑定的服务,或者前面提到的位置独立性之类的需求。有时候,在连接到合作伙伴的系统时,您需要一个联合注册中心服务来定位服务及其绑定详细信息。ESB 应该能够满足您的 SOA 活动的成熟度需求。在某些情况下,处理不同的组织时,您可能需要为服务创建不同的命名空间,以避免名称冲突。这可以通过 ESB 命名空间注册中心得到很好的解决。

协议转换

我们经常期望 ESB 能够对各个层次的协议进行转换,以方便提供者和使用者之间的通信。例如,提供者可能使用 HTTP 提供服务,而使用者可能希望数据采用 SOAP 格式。又如,需要对 HL7V2.X to HL7V3.0 之类的应用层协议进行转换。这可能不是最基本的功能,但却是我们最想要的功能之一,因为这样可以在不同的场景中使用相同的服务。很多时候,甚至 ESB 是否支持特定的协议并进行互操作对确定在特定场景中是否可以使用特定产品都非常重要。

MEP

MEP 非常重要,因为 ESB 通常能够承载任何类型的 MEP。在 SOA 活动中,经常必须支持多个 MEP 类型。与各种应用程序进行集成时,有些可能需要采用事件处理模式工作,而此模式要求必须支持发布-订阅样式的消息交换方式。同时,其他应用程序可能需要采用请求-响应模式工作,以处理其他需求。

技术互操作性

您的 SOA 活动可能构建于不同的技术之上,如专用技术、基于 Java™ 2 Platform enterprise Edition (J2EE) 的技术甚至基于 Microsoft® .NET 的技术。对技术进行归类的另一种方法是划分为 Web 服务、CORBA 或 COM。或者可以根据是基于 Enterprise JavaBeans (EJB)、基于容器还是基于 Spring 框架进行归类。

ESB 应该能够跨使用所有这些技术的服务进行互操作。正如前面提到的,这可能并不仅仅意味着使用基于 J2EE 和 .NET Web 服务,因为服务并不仅仅限于 Web 服务。因此,务必在确定场景的最佳 ESB 产品时确定服务技术需求和产品的技术互操作性能力。

可伸缩性支持

根据您的 SOA 活动的情况,您可能会需要您的 ESB 处理数以千计甚至数以百万计的服务。因此,找到最适合您的 SOA 活动的独特需求的 ESB 产品非常重要。ESB 经常视为重型组件,可能会带来大量开销,限制了其能够支持的可伸缩性。您必须清楚地确定 ESB 伸缩性是否可以满足产品将使用的场景的需求。

响应时间支持

您的 ESB 带来的响应时间开销不应该多于必要响应时间开销。应该在选择 ESB 前对此进行仔细的研究和评估,因为这与 ESB 的可伸缩性需求密切相关。

避免供应商锁定

除非您的 SOA 活动有特定需求,迫使您锁定到一个供应商,否则就应该在 ESB 选择流程中进行考虑,以便在 SOA 需求更改时更换供应商。您的 SOA 解决方案应该能够在需要时进行扩展。这样可以在标识 ESB 产品需求时考虑将来的情况,因为 ESB 将成为您体系结构的中枢。SOA 的成败很大程度上依赖于(如果不是完全依赖的话)ESB 产品的选择。

治理

策略遵从性在任何企业中都是非常重要的一个部分。所有基于 SOA 的企业体系结构都需要支持足够的机制,以确保策略遵从性和违规情况的早期检测。有时候策略与 SOA 活动的安全性及可测试性会产生混淆。尽管某些安全性和可测试性方面可以建模为策略,但并非所有都可以这样处理。而且,策略通常表示企业 策略,这与安全性和可测试性有很大差别。另外,并非所有企业策略都编码为元数据。因此,就像所有其他需求一样,还应该根据需要对您的治理进行处理。

策略通常是系统需要遵循的规则和制度的声明性规范。您还可以将此类规则视为系统的特征。系统的策略可以描述系统的进程、功能、性能或可靠性。其中也可以包括系统各个时间的安全细节。尽管某些安全细节可以作为策略的一部分,但并非所有安全需求都必须成为策略的一部分。有时候通过策略编码系统的安全性更为有效,但策略通常与安全特定的策略及测试特定的策略不同。

典型的治理产品应该:

  • 允许配置遵从特定标准所需的策略,如 Sarbanes-Oxley (SOX) 或 Federal Financial Institutions Examination Council (FFIEC)。
  • 允许监视策略违规行为并在发现此类行为时将其记入日志。还应该允许记录违规行为的足够细节,以便将来对此进行纠正。
  • 允许自动部署策略,包括对策略的更改。

IBM® 提供了一系列治理方面的产品,包括:

  • IBM WebSphere® Business Monitor通过可提高业务用户的仪表盘体验的新可视化功能提高效率。这是治理的高级功能之一,可以让企业进行没有此工具就无法想象的创新。
  • IBM Tivoli® Service Level Advisor提供可预测的服务水平管理功能。此产品属于 IBM Tivoli IT Service Management 产品投资组合,提供了智能管理软件,可通过将 IT 操作与业务优先项实现统一来帮助企业提高操作敏捷性。
  • IBM Tivoli Change and Configuration Management Database帮助通过集成、自动化和优化数据、工作流和策略实现 IT 基础结构的持续管理与业务优先项的一致。
  • IBM Rational® Asset Manager帮助创建、修改、治理、查找和重用任何类型的开发资产,包括 SOA 和系统开发资产。
  • IBM Rational Portfolio Manager允许监视流程和功能,帮助企业将其 IT 及系统投资与业务优先项保持一致。

除了上面列出的 IBM 产品外,AmberPoint 也是一个众所周知的治理产品。

通常,治理产品还应该能够支持 SOA 活动的业务敏捷性需求和监视需求。您的监视能力和报告的范围也可能会受到所选治理产品的限制。因此,仔细选择您的治理产品对 SOA 活动的成功至关重要。

安全性

很多时候,架构师决定从头构建安全基础结构。这种做法虽然在某些情况下不错,但并非总是如此。安全解决方案的选择依赖于以下需求。

信任边界

这与您的 SOA 活动是否跨各种信任边界(同一企业内或跨各种合作伙伴组织)相关。组织的各个部门内的可信度是否会变化,或者是否仅在涉及跨不同组织的用户才会变化?

联合安全性

存在多个需要彼此通信的服务器,这就非常重要了。在这种情况下,您需要建立无缝安全性框架。这方面的一个例子是,在组织内提供合作伙伴组织的访问机制。由于合作伙伴组织的员工和角色由合作伙伴组织控制,因此最好采用联合安全模型。

单点登录 (SSO)

当多个应用程序采用不同的身份验证机制时,SSO 就变得非常重要了。在需要为用户通过 SSO 机制登录的应用程序执行上下文设置时,SSO 还可以帮助无缝地集成应用程序。

身份验证和授权

身份验证和授权机制也可以通过多种方式进行。有些 SOA 活动可能需要混合使用多个身份验证和授权机制并进行匹配。在选择安全解决方案时请仔细考虑这一点。

可测试性

可测试性对 SOA 非常重要,因为有时候必须在生产系统上执行测试。只有生产系统能够提供并发性和可伸缩性需求的测试条件。另外,所有升级都必须只在生产系统中提供。因此必须确定满足您的 SOA 活动的所有可测试性需求的基础结构。如果不满足可测试性需求,整个 SOA 活动可能会由于系统不能继续正确工作而崩溃。

此方法的好处

通过考虑这些方面,您有什么收获?您可以通过为 SOA 活动使用此方法来实现大量好处,具体如下所述。

供应商独立性

您的 SOA 活动的成败应该取决于作为构建基础的业务好处,而不是用于实现它的单个供应商的产品套件。您要根据 SOA 需求选择供应商,以便能够在 SOA 需求发生更改时更换供应商。

保护您的 SOA 解决方案不受并购的影响

很多 SOA 供应商都根据其业务焦点与其他供应商进行了合并,而由于同样的原因,很多供应商被其他供应商所收购。SOA 供应商的业务焦点几乎总是和您 SOA 活动的业务焦点不同,因此,如果您极为依赖某个经历了合并或收购的供应商,则可能会给您的 SOA 活动带来问题。本文中所述的方法可以帮助您处理这些情况。

关注解决方案的需求

有些供应商的产品功能可能过于局限于满足您的 SOA 需求。这可能会导致您的 SOA 产品成为问题集的一部分,而不是解决方案集的一部分——增加其他问题的话,就会需要新的解决方案。通过遵循本文给出的方法可以避免这个失误。

规模恰当的投资

产品供应商经常提供了您 SOA 解决方案中所不需要的大量功能。通过使用这里给出的方法来确定满足您需求的正确 SOA 产品,从而仅在 SOA 解决方案所需的方面进行投资,并从投资获得早期的、更好的回报。

总结

开始 SOA 活动时,请记住本文中最重要的要点:密切关注预期的结果。这样可帮助您避免被行业中无以计数的产品、供应商和技术所打扰,从而极大地提高成功的几率。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=348666
ArticleTitle=基于需求的 SOA 与基于功能的 SOA:确定 SOA 活动的正确焦点
publish-date=10302008