如何进行系统集成？

Question

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

我想知道，如果你开发自己的小服务，然后连接起来，或者如果你使用某种产品(WebSphere，BizTalk，Mule等)，你是否可以解决这个问题。我也想知道这些解决方案是如何管理和维护的(您如何解决安全性、工具等)，您在解决方案中遇到了哪些问题等等。

Answer 1

哇-好吧-我会得到一个帖子，但会很大。

集成需要得到业务对好处的深刻理解的支持--整理出一个可操作的模型--因为业务可能真的需要标准化而不是集成，因为这可能是代价高昂的--这就是为什么大多数面向服务的体系结构失败了！Enterprise Architecture: Driving Business Benefits from IT Author(s): Jeanne W. Ross

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

速度和性能指标是什么？

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

这里的重点是查看规范和业务需求中的性能标准，这将有助于查看您需要执行的集成类型- WebServices (超文本传输协议)、文件删除/电子数据交换等

在功能上，对于集成，您需要查看建议的体系结构中的故障点-因为这将导致SLA/OLA中的响应链。您可能需要将集成点/故障点封装到您控制的对象中。

与业务线集成类似的一点是，在集成之前，您需要对其他产品了解多少？是的，Webservices应该是按合同设计的，但是实现经常会泄露，你需要了解很多关于正在发生的事情--如果这是一个你不能控制抽象的产品，即使webservices泄露到你的intergation技术，也就是BizTalk。

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

SOA和Intergation中的仪器和诊断是很难获得的！-不要让任何光鲜的销售人员试图告诉你不同的观点！是的，妈妈和妈妈，Ent可以做到这一点，UniCenter可以做到。

主要的问题是理解intergation中的错误aka意味着什么，以及如何从它们中恢复。你最终会收到卡住的消息，你需要理解这对忙碌的进程意味着什么。你可以得到一个警告-- processers 100% Ram 100% orchestrations have --但没有真正的含义。你必须从一开始就将这些东西设计到解决方案中-希望能在你的失败点中实现。

集成模式的类型和如何做也需要考虑。

上面是在活动实现中使用BizTalk的.NET SOA的真实视图。但这也是由于它的架构限制- BizTalk主要是一个中心和辐射型模式。

查看Enterprise Application Patterns by Martin Fowler

有很多方法可以给任务换皮！

其他考虑因素...平台/开发人员语言等。

对我们来说，一个重要的因素是开始这些东西所需的技能。我们有了解Java和C#的面向对象开发人员，但主要是C#。所以我们选择了MS堆栈。但是，当你选择集成类型和产品来管理这一点时，他们需要更多的技能来理解这项技术。但是，嘿，这对我们开发人员来说是正常的，对吧？错误的是，许多开发人员，不管有没有经验，都会被BizTalk这样的东西搞砸！范式的重大转变-部分原因是消息传递的转变，而不是代码。

最好的最后一位！

在整合中可能面临的交易数量可能是所有这些交易中最大的单一因素。因为这将指导这类事情的模式、失败点和容忍度。

您需要在防冲突卷上选择最好的正确卷。可以扩展和扩展的东西！我们选择了BizTalk，因为它可以正确地向上和向外扩展，并且比其他一些人更好地理解。

如果你没有卷，那么看一下没有东西来管理它们，去找一个没有管理的webservice to webservice类型的风格-性能和故障理解将需要编码到它们中。

如果你在windows平台上使用.net 3，看看WWF/WCF，因为这可以帮助你从webservice到webservice -现在在acutal平台上有更多的这些问题，而没有BizTalk和其他的开销。

希望这能有所帮助。

Answer 2

根据我的经验，这取决于你处理的是什么类型的问题。

根据我的经验，很难在性价比上超过BizTalk 2006 R2，但它确实意味着使用了微软的技术堆栈。

对于大型企业来说，Websphere MQ似乎更容易销售，而且它可能在企业级得到了更多的使用。

两者都提供了很好的插装，但这实际上是由您作为开发人员对其进行自定义以满足客户需求。

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

Answer 3

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