为了在SOA平台上托管，我们应该迁移应用程序吗？

Question

我有一个关于集成设计的问题。我们采用的是使用JBoss套件的SOA。现在它提出了一个大问题:当我们开发一个新的服务/应用程序时，

1. 我们是否应该在Fuse上托管它，并具体地基于SwitchYard开发它？这个决定导致所有的业务逻辑都会被放到SwitchYard上。

​

1. 或者，我们开发一个基于独立平台的新服务/应用程序(它可以是任何可以公开REST、SOAP服务的开源框架)。这个决定导致服务有自己的业务逻辑。

​

有什么想法吗？

Answer 1

在使用ESB时要记住的一件事是，ESB是集成服务器，而不是应用服务器。ESB的存在是为了方便各种应用程序之间的通信。如果在ESB中构建应用程序，ESB现在被绑定到该应用程序，简而言之，ESB不应该包含业务逻辑。

ESB设计用于执行以下操作：

• 监视和控制服务间消息交换的路由
• 解决通信服务组件之间的争用问题
• 服务的控制部署和版本控制
• 执法人员使用冗余服务
• 满足商品服务，如事件处理、数据转换和映射、消息和事件队列和排序、安全或异常处理、协议转换和强制适当质量的通信服务。

令人困惑的部分是ESB可以“承载”业务逻辑，但它不是合适的位置。让我解释一下。大多数企业都有几个软件包，如CRM、客户数据库和营销数据库。客户关系管理可以有一个用于搜索人员的SOAP接口，客户端数据库可能需要一个SQL查询，而营销数据库可能有一个用于example.All的REST接口--这些系统及其接口称为提供者/生产者。

如果我想创建一个企业范围的人员记录搜索，需要一个搜索工具来与所有提供程序接口进行接口).This是最有意义的地方。

在这个场景中，一种方法可以是设计用于企业范围搜索的SOAP服务。您将创建一个新服务，该服务具有进行搜索所需的操作和数据结构，但不会直接公开提供程序接口。始终在ESB上使用抽象。新服务将将其操作和数据结构映射到提供者数据结构。

因此，您将拥有一个可以调用这三个接口的服务。这样做的最大优点是，例如，当您升级客户数据库以使用REST服务时，您可以更改从企业级服务到客户数据库接口的映射，而无需更改其他服务。

就这么想吧。当您在ESB上公开未将数据使用者绑定到特定提供者的抽象服务时，您可以在后端更改该提供程序并重新进行映射。你的消费者不会受到影响。

一个这样的现实世界的例子是，当银行有不同的银行后端，但他们使用IFX协议相互通信。无论数据提供者是信用卡机器、atm还是SAP银行模块，这都无关紧要。他们都会说IFX。

所以在你的例子中，选择第二种。让应用程序承载业务逻辑，让ESB承载集成。

希望这能帮点忙。