你们是如何进行系统集成的？

Question

我很好奇不同的人如何解决系统集成。我有一种感觉，过去几年越来越多的工作投入到系统集成中，而且这种工作需求也会增加。

我想知道您是否通过开发自己的小型服务来解决这个问题，然后将其连接起来，或者您是否使用某种产品（WebSphere、BizTalk、 骡子 ETC）。我还认为了解如何管理和维护此类解决方案（如何解决安全性、仪器仪表等）、您的解决方案遇到了哪些类型的问题等等会很有趣。

Answer 1

哇 - 好的 - 会得到一个关于这个的帖子，但会很大。

集成需要得到业务对好处的深入理解的支持 - 整理出一个运营模型 - 因为业务可能实际上需要标准化而不是集成，因为这可能成本高昂 - 这就是大多数 SOA 失败的原因！ 企业架构：从IT中驱动业务利益作者：珍妮·W.罗斯

如果需要集成，您需要确定集成类型。

速度和性能指标是什么？

我们有一个带有组合应用程序的 .NET SOA，该应用程序使用 BizTalk 2006 和带有业务线应用程序的 Web 服务。复合端（消耗）的应用程序性能 - 受限于业务应用程序中 Web 服务（及其实现）的速度！我们需要 <3 秒内返回结果 - 案例列表。无法在网络服务中实现，因此我们需要直接进入数据库进行初始搜索。然后通过网络服务创建案例。成本影响和维护成为这里的一个问题。

这里的重点是查看规范和业务需求中的性能标准，这将有助于查看您需要执行的集成类型 - Web 服务 (HTTP)、文件删除/ EDI 等

从功能上来说，为了集成，您需要查看建议架构中的故障点 - 因为这将导致 SLA/OLA 中的责任链。您可能需要将集成/故障点包装到您控制的事物中。

关于与业务线集成的类似点是，在集成之前您需要对其他产品了解多少？是的，Web 服务应该是按合同设计的，但实现经常存在漏洞，您需要了解很多正在发生的事情 - 如果这是一个您无法控制抽象的产品，即使 Web 服务泄漏到您的集成技术（又名 BizTalk）中。

将这两点结合在一起，最好的建议是获得像 BizTalk 这样的集成中心类型 - 将业务应用程序包装在您创建的 Web 服务中 - 这样 BizTalk 端就可以避免抽象泄漏，然后还可以减少故障点因为您已将业务应用程序与集成中心和故障点解耦到单个源而不是编排内部。

SOA 和集成项目中的检测和诊断很难实现！- 不要让任何光鲜亮丽的销售人员尝试以不同的方式告诉您！是的，MOM 和 MOM Ent 可以做到这一点，UniCenter 可以做到这一点。

主要问题是理解插值中的错误又名打嗝的含义以及如何从中恢复......您最终会遇到消息被卡住的情况，您需要了解这对业务流程意味着什么。您可能会收到一条警报说 - 处理器 100% Ram 100% 编排失败 - 但没有真正的意义。您必须从一开始就将这些内容设计到解决方案中，并希望能够解决您的故障点。

集成模式的类型以及如何实现它们也需要考虑。

以上是在实时实现中使用 BizTalk 的 .NET SOA 的真实世界视图。但也正是由于这样的架构限制——BizTalk主要是HUB和SPOKE模式。

查看 企业应用程序模式 作者：Martin Fowler

任务皮肤的方法有很多种！

其他考虑因素...平台/开发者语言等

对我们来说，最重要的因素之一是启动这项工作所需的技能。我们的 OO 开发人员了解 Java 和 C#，但主要是 C#。所以我们选择了 MS 堆栈。但是，当您选择集成类型和产品来管理此问题时，他们将需要更多技能来理解该技术。但是嘿，这对我们开发人员来说很正常，对吧？许多开发人员无论有没有经验都可能会因为 BizTalk 之类的东西而陷入困境！范式的巨大转变——部分原因是消息传递的转变而不是代码。

最好的一点放在最后！

整合中可能面临的交易数量可能是所有这一切中最大的因素。因为这将指导此类事物的模式、故障点和容忍度。

您需要在预期的卷数上选择最合适的。可以扩展和扩展的东西！我们选择 BizTalk 是因为它可以正确地纵向扩展和横向扩展，并且比其他一些方法更好地理解。

如果您没有卷，那么看看是否没有东西来管理它们，并选择没有管理的 Web 服务到 Web 服务类型样式 - 需要将性能和故障理解编码到其中。

如果您使用 .net 3 的 Windows 平台，请查看 WWF/WCF，因为这可以在 Web 服务之间提供帮助 - 现在，在实际平台中可以提供更多帮助来解决所有这些问题，而无需 BizTalk 和其他服务的开销。

希望这可以帮助。

Answer 2

根据我的经验，这取决于您要解决的问题类型。

根据我的经验，很难在性价比上击败 BizTalk 2006 R2，但它确实意味着使用 Microsoft 技术堆栈。

Websphere MQ 似乎更容易销售给大型企业，并且可能在企业级别得到更多使用。

两者都提供了良好的工具，但实际上取决于您作为开发人员来自定义它以满足客户的要求。

在某些情况下，我发现定制解决方案是最合适的，或者利用 MSMQ 等技术来降低成本。

Answer 3

您提到了 WebSphere、BizTalk、Mule。每个都有非常不同的特点，有其优点和缺点。如果您只是追求集成，我会推荐 Mule。我对此有很好的经验，更重要的是，架构师是非侵入性的，因此您始终可以迁移到不同的 ESB 或其他流行语投诉解决方案。Mule 的优点之一是它可以嵌入到您的应用程序中，并且您的最终工件可以部署在 Webshpere、WLS、Glassfish 等上......甚至没有显示您嵌入了 ESB。然后这个 ESB 可以执行所有集成管道（管理连接类型和协议）。而某些端点可能是您提到的其他集成解决方案。

Answer 4

我们使用 Mule 一段时间了（现在研究从 1.4 到 2.1.x 版本的迁移）。

嗯，它是最好的 ESB 之一，具有实时社区和供应商方面的快速反应，但 IMO 版本 2.1.x 仍然有点原始（或者我们只是使用它来调用 CXF Web 的公司:) 另请参阅我的帖子了解详细信息 http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)

Answer 5

我们有甲骨文合同。所以我们使用 Oracle Stack。SOA 套件 10.1.3.4。主要是 BPEL 解决方案，对于简单的转换，我们尝试使用 ESB。

ESB 的故障处理机制很糟糕。对于 BPEL 有很多方法来处理错误。我们尝试开发java webservices来连接SOA Suite，我们的主要系统是Oracle EBS系统。它们通过 SOA Suite 附带的默认 EBS 适配器与遗留系统或其他 EBS 环境进行通信。

我们遇到的问题是缺乏对 EBS 适配器的了解。我们在从 EBS 系统接收信息的 BPEL 解决方案中遇到了一些问题。准备解决方案生产是一项艰巨的工作。

保护我们的网络服务并不是一个大问题。Oracle 堆栈附带了 Oracle Web 服务管理器。这样我们就可以保护、记录等。所有网络服务。

我们遇到的最大问题是缺乏自己的标准。让企业感觉他们也可以构建 SOA 解决方案。我们无法解释他们通过 SOA 解决方案获得的好处。快点？不 ！更便宜吗？一定不行！更简单的解决方案？好吧，也许当我们获得良好的可重用服务时......好吧，那个更简单的部分有一个问题：我们如何知道哪些应用程序使用可重用的 Web 服务？

我们需要一个寄存器，可以显示此类信息。因为我们找不到好的开源解决方案，所以我们正在尝试构建自己的寄存器。简单的 APEX 解决方案，同样来自 Oracle 堆栈。;)

那么有人知道有什么好的产品可以注册此类信息吗？