2008-08-15 58 views
5

我很好奇不同的人如何解决系统的整合。我有一种感觉,就是最近几年越来越多的工作已经进入整合系统,这种工作需求也会增加。你如何做系统整合?

我想知道你是否解决了它开发自己的小型服务,然后连接或者如果你使用某种产品(WebSphere,BizTalk,Mule等)。我也认为了解如何管理和维护这些解决方案(您如何解决安全性,仪器等等),您遇到的解决方案遇到了哪些问题等都很有趣。

回答

10

哇 - 好吧 - 会在这个帖子上发帖,但会很大。

集成需要在企业获得好处的情况下得到很大理解的支持 - 获得一个可操作的模型 - 由于业务可能非常需要标准化而不是集成,因为这可能代价高昂 - 为什么大多数SOA失败! Enterprise Architecture: Driving Business Benefits from IT Author(s): Jeanne W. Ross

如果需要整合,则需要解决整合类型。

什么是速度和性能指标?

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

在这里点是看性能标准的规范和业务需求,这将在看看整合式帮助,你需要做的 - Web服务(HTTP),文件拖放/ EDI等

在功能上,为了整合,您需要查看所提出的架构中的失败点,因为这将导致SLA/OLA中的一系列责任。您可能需要将集成/失败点包装到您控制的事物中。

关于与业务线集成的相似点,您需要先了解其他产品需要多少钱?是的,Webservices应该是按合同设计的,但实现往往是漏洞,你需要了解有关正在发生的事情 - 如果这是一个产品,即使Web服务泄漏到你的综合技术(又称BizTalk)中,你不控制抽象。

将这两点结合在一起,您最好的建议是获得像BizTalk这样的集成中心类型 - 在您创建的webservices中封装业务应用程序的行 - 所以BizTalk方面可以免于泄漏抽象,那么您也可以减少因为您已将业务线应用程序从集成中心和失败点解耦为单一源而不是在编排中。

SOA和Intergation中的仪器和诊断对象很难达到! - 不要让任何闪耀的销售人员尝试以不同的方式告诉你!是的MOM与MOM的妈妈可以做到这一点UniCenter可以做到这一点。

主要问题是要了解集成中的错误aka意味着什么,以及如何从中恢复......您最终会遇到消息停滞,并且您需要了解这个业务流程的含义。你可以得到一个警告 - 处理器是100%Ram 100%编排失败 - 但没有真正意义。你必须从一开始就把这些东西设计到解决方案中 - 并希望进入你的失败点。

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

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

退房Enterprise Application Patterns by Martin Fowler

有很多方法对皮肤的任务!

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

一种为我们的大因素是开始这个​​东西所需要的技能。我们有OO开发人员对Java和C#的理解,但主要是C#。所以我们去了MS堆栈。但是,当您选择整合类型和产品来管理这些时,他们需要更多技能来理解该技术。但是,嘿,这对我们来说是正常的吗?错误的许多开发人员,无论那里expereince可以与诸如BizTalk的喜欢取消!范式的巨大转变 - 部分原因是由于消息转移而不是代码。

最后一点!

整合中可能面临的交易数量很可能是所有这一切中最大的一个因素。因为这将指导什么样的模式,失败点和对这些事情的宽容。

您需要在正确的卷上选择最好的反卷。一些可以扩大和扩大的东西!我们之所以选择BizTalk,是因为它可以正确扩展和扩展,并且比其他人有更好的理解。

如果你没有卷,然后看看没有得到的东西来管理它们,并寻求web服务web服务类型的风格,没有管理 - 性能和失败的理解将需要编码到他们。

如果您在Windows平台上使用.net 3,请查看WWF/WCF,因为这可以帮助将web服务转换为webservice - 现在有更多的acutal平台可以解决所有这些问题,而不会造成BizTalk和其他人的开销。

希望这会有所帮助。

0

根据我的经验,这取决于你正在解决什么样的问题。

以我的经验来说,很难击败BizTalk 2006 R2以获得巨大回报,但它确实意味着使用Microsoft技术堆栈。

Websphere MQ似乎更容易向大型企业销售,并且可能在企业级应用更广泛。

两者都提供了良好的仪器功能,但作为开发人员,您可以根据自己的客户需求进行定制。

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

0

您提到了WebSphere,BizTalk,Mule。其中每一个的优点和缺点都有很不相同的特点。 如果你只是集成后,我会建议骡子。我对它有非常好的经验,更重要的是架构师非侵入性,因此您可以随时迁移到不同的ESB或其他Buzz字词投诉解决方案。 Mule的甜蜜之处在于它可以嵌入到您的应用程序中,并且您的最终工件可以部署在Webshpere,WLS,Glassfish等等......甚至不需要嵌入ESB。然后这个ESB可以执行所有的集成管道(管理连接类型和协议)。而一些端点可能是您提到的其他集成解决方案。

0

我们有一个Oracle合同。所以我们使用Oracle Stack。 SOA套件10.1.3.4。大多数BPEL解决方案和我们试图使用ESB的简单转换。

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

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

保护我们的web服务不是一个大问题。随Oracle数据仓库一起提供Oracle Web服务管理器。有了这个,我们可以保护,记录所有的web服务。

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

我们需要一个寄存器,可以显示这种信息。由于我们无法找到一个好的开源解决方案,我们正在努力建立自己的注册表。简单的APEX解决方案,再次来自Oracle堆栈。 ;)

那么有人知道一个好的产品来注册这种信息?