5

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

我想知道您是否可以通过开发自己的小型服务来解决它，然后再连接，或者您是否使用某种产品（WebSphere、BizTalk、Mule等）。我还认为了解如何管理和维护这些解决方案（您如何解决安全性、仪器等）、您的解决方案遇到过什么样的问题等等会很有趣。

4

5 回答 5

10

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

集成需要得到业务对好处的深刻理解来支持 - 整理出一个运营模型 - 因为业务可能实际上需要标准化而不是集成，因为这可能代价高昂 - 这就是大多数 SOA 失败的原因！企业架构：从 IT 中获得业务收益 作者：Jeanne W. Ross

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

速度和性能指标是什么？

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

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

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

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

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

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

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

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

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

查看Martin Fowler 的企业应用程序模式

有很多方法可以完成任务！

其他注意事项...平台/开发者语言等

对我们来说，重要的因素之一是开始这些东西所需的技能。我们有了解 Java 和 C# 的 OO 开发人员，但主要是 C#。所以我们选择了 MS 堆栈。但是，当您选择集成类型和产品来管理它时，他们将需要更多技能来理解该技术。但是，嘿，这对我们开发人员来说很正常，对吧？错误的许多开发人员，无论有没有经验，都可能无法使用 BizTalk 之类的软件！范式的重大转变——部分原因是消息传递而不是代码。

最后一点最好！

集成中可能面临的交易数量可能是所有这一切中最大的一个因素。因为这将指导什么模式、故障点和对此类事情的容忍度。

您需要在预期的卷上选择最好的那个。可以扩大和扩大规模的东西！我们选择 BizTalk 是因为它可以正确扩展和扩展，并且比其他一些更好地理解。

如果你没有卷，那么看看没有什么东西来管理它们，并采用没有管理的 webservice 到 webservice 类型的样式 - 需要将性能和故障理解编码到它们中。

如果您在带有 .net 3 的 Windows 平台上查看 WWF/WCF，因为这可以帮助 web 服务到 web 服务 - 现在在实际平台中更多地解决所有这些问题，而无需 BizTalk 和其他人的开销。

希望这可以帮助。

于 2008-08-15T07:10:14.217 回答
0

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

根据我的经验，很难以物超所值的价格击败 BizTalk 2006 R2，但它确实意味着使用 Microsoft 技术堆栈。

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

两者都提供了良好的仪器，但作为开发人员，您可以根据客户的要求对其进行自定义。

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

于 2008-08-15T15:44:50.313 回答
0

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

于 2008-09-04T20:12:06.497 回答
0

我们使用 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 )

于 2008-11-01T19:46:24.480 回答
0

我们有一份甲骨文合同。所以我们正在使用 Oracle 堆栈。SOA 套件 10.1.3.4。大多数是 BPEL 解决方案，对于简单的转换，我们尝试使用 ESB。

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

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

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

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

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

那么有人知道注册这种信息的好产品吗？

于 2008-12-25T21:44:35.880 回答