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

我很好奇不同的人如何解决系统的整合.我有一种感觉,在过去的几年里,越来越多的工作已经用于集成系统,并且这种工作需求也会增加.

我想知道你是否解决了它开发你自己的小服务然后连接或如果你使用某种产品(WebSphere,BizTalk,Mule等).我也认为知道如何管理和维护这些解决方案(如何解决安全性,仪表等等),解决方案遇到了什么样的问题等等,这一点很有意思.

哇 - 好的 - 会有关于此的帖子,但会很大.

需要通过业务对利益的深刻理解来整合集成 - 获取一个操作模型 - 因为业务可能需要标准化而不是集成,因为这可能代价高昂 - 这是大多数SOA失败的原因!企业架构:推动IT作者的业务收益:Jeanne W. Ross

如果需要整合,那么您需要确定整合的类型.

什么是速度和性能指标？

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

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

在功能上,您需要查看所提出的体系结构中的故障点 - 因为这将导致SLA/OLA中的响应可靠性链.您可能需要将整合/混合点包装到您控制的事物中.

关于与业务线整合的类似观点是,在集成之前,您需要了解多少其他产品？是的Webservices应该是按合同设计的,但是实现通常是漏洞而且你需要了解很多正在发生的事情 - 如果这是一个你不控制抽象的产品,即使web服务泄漏到你的集成技术也称为BizTalk.

将这两点结合在一起,您最好的建议是获得像BizTalk这样的集成中心类型 - 将您创建的Web服务中的业务应用程序包装起来 - 这样BizTalk方面就可以免于泄漏抽象,那么您也可以减少故障点因为您已将业务线应用程序从集成中心和故障点分离到单个源而不是在业务流程内.

SOA和Intergation项目中的仪器和诊断很难实现! - 不要让任何光鲜的销售人员试着用不同的方式告诉你!是的MOM与MOM Ent可以做到这一点UniCenter可以做到.

主要的问题是了解错误在整合意味着什么,以及如何从中恢复...最终你的消息被卡住了,你需要了解这对于那个业务流程意味着什么.你可以得到警告 - 处理器100%Ram 100%编排失败 - 但没有实际意义.你必须从一开始就将这些东西设计到解决方案中 - 并希望你能找到失败的地方.

需要考虑整合模式的类型以及如何进行这些模式.

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

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

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

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

对我们来说,最重要的因素之一是启动这些东西所需的技能.我们有OO开发人员对Java和C#的理解,但主要是C#.所以我们去了MS堆栈.但是当您选择集成类型和产品来管理它时,他们将需要更多技能来理解该技术.但嘿,这对我们Devs来说是正常的吗？错误的许多开发人员,无论有什么经验,都可以与BizTalk之类的东西脱颖而出!范式的重大转变 - 这部分是由于消息传递而不是代码.

最后一点!

可能在整合中面临的交易数量可能是所有这一切中最重要的因素.因为这将指导这些事情的模式,失败点和容忍度.

你需要选择最好的防伪卷.可以扩展和扩展的东西!我们选择了BizTalk,因为它可以正确地扩展和扩展,并且比其他人更好地理解.

如果你没有卷,那么看看没有得到管理它们的东西,并且在没有管理的情况下去web服务到web服务类型样式 - 需要将性能和失败理解编码到它们中.

如果您在Windows平台上使用.net 3,请查看WWF/WCF,因为这可以帮助webservice到webservice - 现在更多的是在acutal平台上解决所有这些问题,而不需要BizTalk和其他人的开销.

希望这可以帮助.