我很好奇不同的人如何解决系统的整合。我有一种感觉，过去几年越来越多的工作已经用于整合系统，这种工作需求也会增加。
我想知道你是否解决了它开发你自己的小服务然后连接或者你使用某种产品（WebSphere，BizTalk，Mule等）。我也认为了解如何管理和维护这些解决方案（如何解决安全性，仪表等等），解决方案遇到了什么样的问题等等，这一点很有意思。
答案 0 :(得分：10)
如果需要整合，则需要确定整合的类型。
速度和性能指标有哪些？
我们有一个带有复合应用程序的.NET SOA，它使用BizTalk 2006和Web服务与业务线应用程序。复合端应用程序的性能（消耗） - 仅限于业务应用程序中的Web服务（及其实现）的速度！我们需要小于＆lt; 3秒的结果返回 - 案例列表。无法在Web服务中实现，因此我们需要直接进入数据库进行初始搜索。然后通过Web服务创建案例。成本影响和维护成为一个问题。
这里的重点是查看规范和业务需求中的性能标准，这将有助于查看您需要执行的集成类型 - Web服务（HTTP），文件丢弃/ EDI等
在功能上，您需要查看所提出的体系结构中的故障点 - 因为这将导致SLA / OLA中的响应可靠性链。您可能需要将整合/混合点包装到您控制的内容中。
关于与业务线整合的类似观点是，在集成之前，您需要了解多少其他产品？是的Webservices应该是按合同设计的，但是实现通常是漏洞而且你需要了解很多正在发生的事情 - 如果这是一个你不控制抽象的产品，即使web服务泄漏到你的集成技术也称为BizTalk。 / p>
将这两点结合在一起，你最好的建议是获得像BizTalk这样的集成中心类型 - 包装你创建的web服务中的业务应用程序行 - 所以BizTalk方面可以没有漏洞抽象，那么你也可以减少您已将业务线应用程序从集成中心和故障点分离到单个源而不是在业务流程内部，从而将故障点解决。
SOA和Intergation项目中的仪器和诊断很难实现！ - 不要让任何光鲜的销售人员试着用不同的方式告诉你！是的MOM与MOM Ent可以做到这一点UniCenter可以做到。
主要问题是了解错误在整合意味着什么，以及如何从中恢复...最终导致消息陷入困境，您需要了解这对业务流程意味着什么。你可以得到警告 - 处理器100％Ram 100％编排失败 - 但没有实际意义。你必须从一开始就将这些东西设计到解决方案中 - 希望能够成为你的失败点。
需要考虑整合模式的类型以及如何进行这些模式。
以上是在LIVE实现中使用BizTalk的.NET SOA的真实世界视图。但这也是由于它的架构限制 - BizTalk主要是HUB和SPOKE模式。
查看Enterprise Application Patterns by Martin Fowler
有很多方法可以完成任务！
其他考虑因素......平台/开发人员语言等。
对我们来说，最重要的因素之一是启动这些东西所需的技能。我们有OO开发人员对Java和C＃的理解，但主要是C＃。所以我们去了MS堆栈。但是当您选择集成类型和产品来管理它时，他们将需要更多技能来理解该技术。但嘿，这对我们Devs来说是正常的吗？错误的许多开发人员，无论有什么经验，都可以与BizTalk之类的东西脱颖而出！范式的重大转变 - 这部分是由于消息传递而不是代码。
最后一点！
集成中可能面临的交易数量很可能是所有这些中最重要的因素。因为这将指导这些事情的模式，失败点和容忍度。
你需要选择最好的防伪卷。可以扩展和扩展的东西！我们选择了BizTalk，因为它可以正确地扩展和扩展，并且比其他人更好地理解。
如果你没有卷，那么看看没有得到管理它们的东西，并且在没有管理的情况下去web服务到webservice类型样式 - 需要将性能和失败理解编码到它们中。
如果您在Windows平台上使用.net 3，请查看WWF / WCF，因为这可以帮助Web服务到Web服务 - 现在更多关于所有这些问题的实际平台，而不需要BizTalk和其他人的开销。
希望这有帮助。
答案 1 :(得分：0)
根据我的经验，这取决于你正在解决的问题。
根据我的经验，很难击败BizTalk 2006 R2，但它确实意味着使用了Microsoft技术堆栈。
Websphere MQ似乎更容易出售给更大的企业，它可能在企业级别上有更大的用途。
两者都提供了良好的仪器，但作为开发人员，您可以自行定制，以满足客户的要求。
在某些情况下，我发现定制解决方案是最合适的或利用MSMQ等杠杆技术来降低成本。
答案 2 :(得分：0)
你提到过WebSphere，BizTalk，Mule。每个都有不同的特点及其好坏点。 如果只是整合你，我会推荐骡子。我对它有非常好的经验，更重要的是架构师是非侵入性的，因此您可以随时迁移到不同的ESB或其他Buzz字投诉解决方案。 Mule的一个优点是它可以嵌入到您的应用程序中，您的最终工件可以部署在Webshpere，WLS，Glassfish等上......甚至没有显示您嵌入了ESB。然后，此ESB可以执行所有集成管道（管理连接类型和协议）。而一些终点可能是您提到的其他集成解决方案。
答案 3 :(得分：0)
我们正在使用Mule一段时间（现在调查从1.4到2.1.x版本的迁移）。
那么它是最好的ESB之一，有实时社区和供应商方面的快速反应，但IMO版本2.1.x仍然有点原始（或者我们只是使用它来呼叫CXF网站的公司:)参见我的发布详情http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320）
答案 4 :(得分：0)
ESB的故障处理机制很糟糕。对于BPEL，有许多方法可以处理错误。我们尝试开发java webservices以连接到SOA Suite，我们的主要系统是Oracle EBS系统。它们通过SOA Suite附带的默认EBS适配器与遗留系统或其他EBS环境进行通信。
我们遇到的问题是缺乏关于EBS适配器的知识。我们遇到了一些BPEL解决方案的问题，该解决方案从EBS系统接收信息。让解决方案生产准备就绪是一项艰巨的任务。
保护我们的网络服务不是一个大问题。 Oracle Web Service Manager带有Oracle堆栈。有了它，我们可以保护，记录等所有的网络服务。
我们遇到的最大问题是缺乏自己的标准。让企业感觉他们也可以构建SOA解决方案。我们无法解释他们使用SOA解决方案获得的好处。快点？不！便宜？一定不行！解决方案更简单？好吧，也许当我们获得良好的可重用服务......好吧，更容易的部分内部存在问题：我们如何知道哪些应用程序使用可重用的Web服务？
我们需要一个可以显示此类信息的寄存器。因为我们找不到好的开源解决方案，所以我们正在尝试构建自己的寄存器。简单的APEX解决方案，再次来自Oracle堆栈。 ;）
所以有人知道注册这类信息的好产品吗？