ibm-soa编程模型_SOA编程模型

ibm-soa编程模型

随着面向服务的体系结构的采用率提高，由Web服务API（当今最流行的SOA实现技术）（例如Java中的JAX-RPC或Web服务扩展（ .Net中的API不足以有效实施SOA：

• 这些API的语义更适合于服务调用和SOAP处理的技术方面，然后更适合于服务的使用和支持。
• 它们中的大多数仅提供SOAP over HTTP支持^a ，这对于SOA实现而言并不总是最佳的传输方式。
• 
  
• 它们中的大多数仅提供同步和单向服务调用^b ，它们仅是服务交互样式的子集。
• 这些API直接暴露于实现代码，导致以下内容：
  • 业务实现代码通常与服务通信支持相互交织，这使其难以实现，理解，维护和调试。
  • 任何API更改（通常每年至少发生一次）都需要更改业务实施。
• 这些API不直接支持许多重要的服务运行时模式。 例如，动态路由的实现需要自定义编程和使用其他API（Java中的JAX-R）来访问注册表。

为了解决当前API集的某些问题，目前正在尝试通过定义SOA编程模型（从其他技术中借来许多元素）来提高抽象水平，目的是降低应用程序开发人员的复杂性。当它们直接与特定于中间件或Web服务的API进行交易时会遇到的风险。 通过从业务代码中删除大部分通信支持并将其隐藏在编程模型抽象/实现的后面，此方法可简化¹ ：

• 简化业务服务的发展
• 简化了作为服务网络构建的业务解决方案的组装和部署
• 敏捷性和灵活性更高
• 通过避免低级技术变更来保护业务逻辑资产
• 改善的可测试性

创建这种类型的模型的最初尝试之一是Web服务调用框架（WSIF） ^{2 3，}最初由IBM提出，目前是Apache基金会的一部分。

WSIF尝试使服务使用模型与基于WSDL的服务定义保持一致-WSIF API直接支持WSDL语义。 这使WSIF能够为不同传输上的服务的不同实现提供通用的调用模型。 尽管WSIF本身从未得到广泛采用，但是它被许多BPEL引擎（例如IBM的WPC和Oracle的BPEL Manager）用作服务调用的API。

当前在SOA实现中最受欢迎的三种模型是：

• Microsoft的Windows Communication Foundation（Indigo）编程模型，该模型试图通过为所有服务工件创建统一的OO模型来简化服务编程。
• Java Community Process的Java业务集成（JBI）模型，通过以专用（服务）容器的形式创建服务抽象层来解决服务编程的复杂性和可变性。
• 来自IBM，BEA，IONA，Oracle，SAP，Siebel，Sybase等的服务组件体系结构（SCA）的前提是，“具有良好定义的接口和明确的组件职责的，结构良好的基于​​组件的体系结构可以完全有理由被视为SOA” ⁴ 。

这些编程模型通过无缝地结合服务编排支持和成功实现SOA所需的许多模式，试图超越仅服务调用。 它们还充当实现企业服务总线的基础。 在本文中，我们将简要概述每个编程模型。

靛蓝编程模型

Indigo是Microsoft针对面向服务的体系结构的编程模型的最新实现，它支持用于“创建，使用，处理和传输消息”的多种技术。 Indigo计划与Windows Vista的下一版本一起发布。

服务在Indigo中定义为一个程序，该程序公开了端点的集合，每个端点定义为三个主要元素的组合⁵ ：

• 端点地址-可以访问端点的网络地址。
• 端点的绑定指定了其他细节，这些细节定义了与端点的通信，包括传输协议（例如TCP，HTTP）和策略编码（例如文本，二进制），安全性要求（例如SSL，SOAP消息安全性）等。
• 该端点公开的端点的操作的合同规范，这些操作使用的消息以及消息交换模式（MEP）（例如单向，双工和请求/答复）。

通过允许通过具有不同绑定和端点协定（QoS）的多个端点公开相同的功能（服务），该定义有效地扩展了基于WSDL的服务定义。

Indigo编程模型的基础是SOA编程各个方面的OO实现。

SO实体	OO实体	注解
服务合约	接口	用[ServiceContract]注释接口
服务运营	方法	使用[OperationContract]注释接口方法
实现类	类	用[ServiceBehavior]注释类，并从服务协定接口派生它。
实施方法	方法	使用[OperationBehavior]注释方法
数据合约	类	用[DataContract]注释类，并用[DataMember]注释其成员

表1 Indigo中SO实体与OO实体的关系

表1显示了SO和OO概念之间的映射（由Indigo编程模型定义）以及将它们链接在一起的注释⁶ 。 SO和OO的这种融合同时是Indigo的主要优点和缺点：

• OO是大多数开发人员都熟悉的公认的范例。 这意味着可以使用熟悉的技术开始开发新的面向服务的体系结构解决方案。 在这种情况下，Indigo运行时在幕后将OO样式调用转换为可互操作的SOAP消息以进行通信。
• SO与OO显着不同。 将OO用作定义和实现服务的机制可能会导致严重的实现不匹配（粒度，耦合等），这可能会导致次优甚至非常糟糕的面向服务的体系结构实现。

Indigo支持两种主要的服务调用方法：

• 带有类型化参数列表的RPC样式调用（同步和异步）（初始Web服务愿景）。 这种类型的服务调用类似于在分布式对象和RPC实现中使用的传统方法调用。 消息传递样式调用（同步和异步）。 这些类型的服务调用类似于传统的消息传递系统（与本书前面介绍的语义消息传递相比）。

根据访问服务提供的类型（RPC与消息传递），可以以接口（RPC）或消息（消息）协定的形式定义其协定（请参见表1）。

Indigo的另一个基本功能是引入连接器-托管框架，提供安全可靠的通信-用于访问服务端点。 连接器的使用减少了构建互操作服务所需的“管道代码”的数量，因此简化了“连接系统”网络^7的创建 。 这是通过将“管道”分为单独的类（类层次结构）并在大多数情况下提供“标准”实现来实现的。

Indigo连接器使用少量概念（端口，消息，通道）来允许调用与传输或目标平台无关的服务。 这些概念中最重要的是通道，它表示用于向端口发送消息和从端口接收消息的核心抽象。 Indigo ^5中定义了两类渠道：

• 传输通道处理对特定传输（例如HTTP，TCP，UDP或MSMQ）的支持，以及拓扑（例如，点对点，通过中介的端对端，对等，发布和订阅）的支持。
• 协议通道处理对特定QoS特性的支持，例如，安全通道对消息进行加密并添加安全标头。 Indigo使用WS- * ^c规范来实现协议通道。 遵循标准使Indigo的实现可基于WS- *投诉实现^d与其他系统互操作。

靛蓝也支持通道的概念，即通道在另一个通道之上的分层。 例如，安全协议通道可以在HTTP传输通道上分层，以提供HTTP上的安全通信。

Indigo连接器具有对包括防火墙，代理和应用程序级网关在内的中介的支持。 这些中介是成功实施SOA所需的许多模式的基础，包括消息验证，安全性实施，传输交换，监视和管理，负载平衡和基于上下文的路由。

除了支持创建业务服务之外，Indigo还提供了几种系统服务，任何业务服务实现都可以使用它们。 此类服务的示例包括：

• 身份联盟。 该服务基于WS-Federation，并支持企业内部和外部信任边界的身份管理和验证。 它的实现提供了服务和相应的信任权限之间的身份验证代理。
• 交易支持。 该服务基于WSAtomicTransactions规范，并简化了基于服务的事务编程（它支持SQL Server，ADO.NET，MSMQ，分布式事务处理协调器（DTC）等）。

JBI编程模型

利用社区中托管应用程序的应用程序服务器的成功，Java社区流程的JBI实现基于服务容器的概念。

如Java业务集成中所定义。 IEEE Internet Computing ^8- “ JBI是一种由容器和插件组成的可插拔体系结构。该容器承载可通过消息路由器进行通信的插件组件。在体系结构上，组件通过抽象服务模型进行交互，该抽象服务模型是驻留在服务器上的消息传递模型。高于任何特定协议或消息编码格式的抽象级别。”

在基于JBI的实现中，服务不会直接相互交互。 相反，类似于EAI实现中广泛采用的消息代理体系结构，JBI容器充当服务之间的通用中介路由消息（图1）。

图1通过JBI进行的中介消息交换

在JBI体系结构^9的基础上进行交换的参与者之间的这种分离提供了服务提供者和使用者之间的分离层，同时提供了一个定义明确的位置来中介服务流量（插入所有其他必需的功能） ^e 。

在这种情况下，中介可以支持多种功能，从消息转换和安全实施到基于内容的路由和服务版本控制。

JBI容器承载两种不同类型的插件组件⁹ ：

• 服务引擎（SE）。 SE本质上是JBI环境^f内部用于托管服务提供商和服务使用者的标准容器。 JBI环境中经常出现的SE的示例是数据转换器，业务规则容器和BPEL引擎。
• 绑定组件（BC）。 BC向JBI环境外部的服务使用者和提供者提供连接。 BC允许集成不提供Java API的组件/应用程序，并使用远程访问技术来访问它们。

插件组件之间的交互使用基于WSDL 2.0的标准化服务定义。 WSDL 2.0定义在服务使用者和提供者之间提供了共享的理解，并且是JBI实现中互操作性的基础。

除了标准化的服务定义，JBI还使用“标准化”消息的概念来支持全局组件的互操作性。 消息规范化允许将协议和特定于业务的上下文映射成通用的可传输方式，并且在概念上类似于EAI实现^g经常使用的“规范”消息表示形式。

每个JBI容器都存在于单个JVM中，并容纳属于该容器的所有BC和SE，以及一组服务，为SE和BC的实现提供操作支持。

JBI还定义了一套基于JMX的标准控件，这些控件允许外部管理工具执行各种系统管理任务以及管理组件本身。 此管理支持为⁹提供了标准机制：

• 安装插件组件。
• 管理插件组件的生命周期（停止/启动等）
• 将服务工件部署到组件。

服务组件架构

尽管将服务组件体系结构（SCA） ¹⁰定义为一种规范，该规范定义了使用面向服务的体系结构构建系统的模型，但它实际上是一种用于将组件组合为服务的模型，以扩展支持将服务组合为解决方案。

SCA基于两个主要的元模型¹¹ ：

• 类型元模型
• 组成元模型

类型元模型

这个元模型（图2）描述了组件类型，接口和数据结构¹¹ 。

图2组件，接口及其依赖性的元模型

组件实现由以下四组规范^10定义 ：

• 提供的接口一组由组件定义的接口。 这些接口通常定义为WSDL端口类型或语言接口，例如Java或C ++。 一个组件可以公开零个或多个接口。 每个接口由几种方法组成。
• 组件实现所使用的接口的必需规范（参考）集。 这些接口通常定义为WSDL端口类型或语言接口，例如Java或C ++。 组件可以具有零个或多个引用。
• 可以在组件上设置以定制或自定义其行为的属性。 每个属性都定义为一个property元素。 组件可以包含零个或多个属性元素。
• 定义构件实现的实现工件。 SCA允许许多不同的实现技术，例如Java，BPEL，C ++，SQL等。SCA定义了一种用于引入新实现类型的可扩展性机制。

组成元模型

这个元模型（图3）定义了组件实例及其连接方式¹¹ 。

图3组件实例及其在组合元模型中的连接

此元模型中的实例概念与OO中使用的实例概念不同。 这里的组件实例是具有完整解析属性集的组件实现，可以修改组件行为以解决特定问题。

合成定义了许多相互交互的组件实例，其中使用导线定义了交互。

SCA中的布线可以抽象出大多数基础结构级别的代码（类似于Indigo中的通道）。 例如，可以将连线定义为同步或异步，支持组件调用的事务行为，等等。SCA在幕后处理此基础结构详细信息。 电线还可以沿任一方向在不同的接口语言（例如Java接口和WSDL portType /接口）之间进行连接，只要这两种接口类型定义的操作是等效的即可。

除电线外，SCA还支持通过特殊类型的组件（导入和导出）进行模块间通信。 布线，导入和导出组件的组合，允许引用外部服务的组件。

由组成元模型定义的组件组成与服务组成既相似又不同，尽管它们两者都定义了使组件/服务协同工作的方式。 服务组合允许通过组合本身引入的功能来增强参与服务的功能，而此元模型仅定义组件之间的连接（更接近服务实现）。

SCA实现依赖于服务数据对象（SDO） ¹⁰ ，提供了表示数据通用模型的技术。 SDO是组件交互中数据交换的基础。 SDO体系结构中的基本概念是数据对象-存放原始类型的数据和/或其他数据对象的容器。 有关包含的数据的信息由元数据提供，由数据对象显式引用。 SDO中数据对象的组合由数据图表示。 除了对象本身之外，此图还包含一个更改摘要，用于记录有关在处理过程中该图中哪些数据对象和属性已更改的信息（类似于Microsoft环境中的ADO）。 除了SDO之外，SCA还引入了服务消息对象（SMO），该对象提供了一个抽象层来处理和处理在服务之间交换的消息（与JBI中的规范化消息相比）。

SCA目前尚处于起步阶段（在撰写本文时为0.9版），并且不支持SOA实施所需的大多数模式。 取而代之的是，IBM-Websphere ESB / WPS 6.0的当前SCA实现引入了基于SCA的中介框架¹² ，并提供了用于实现和放置中介的明确定义的机制（类似于Indigo中的中介）。

当GUI支持SCA实施时，SCA实施特别强大，允许以调色板的方式图形化面板上的组件，这是在IBM WebSphere Integration Developer（WID） ^{13 14中实现的方式} 。

翻译自: https://www.infoq.com/articles/SOA-programming-models/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

ibm-soa编程模型