我很好奇不同的人如何解决系统集成。 我有一种感觉，过去几年越来越多的工作投入到系统集成中，而且这种工作需求也会增加。
我想知道您是否通过开发自己的小型服务来解决这个问题，然后将其连接起来，或者您是否使用某种产品（WebSphere、BizTalk、骡子等）。 我还认为了解如何管理和维护此类解决方案（如何解决安全性、仪器仪表等）、您的解决方案遇到了哪些类型的问题等等会很有趣。
I curious to how different people solve integration of systems. I have a feeling that the last years more and more work has gone into integrating systems and that this kind of work need will increase as well.
I wondering if you solve it developing your own small services that are then connected or if you use some sort of product (WebSphere, BizTalk, Mule etc). I'd also think it'd be interesting to know how these kind of solutions are managed and maintained (how do you solve security, instrumentation etc, etc), what kind of problems have you experienced with your solution and so on.
发布评论
评论（5）
我们使用 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)
We are using Mule for a while (now investigate migration from 1.4 to 2.1.x version).
Well It's one of the best ESB with live community and quick reaction from vendor side, but IMO version 2.1.x is still a bit raw (or we are only the company that use it for calling CXF web :) see also my post for details http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)
您提到了 WebSphere、BizTalk、Mule。 每个都有非常不同的特点，有其优点和缺点。
如果您只是追求集成，我会推荐 Mule。 我对此有很好的经验，更重要的是，架构师是非侵入性的，因此您始终可以迁移到不同的 ESB 或其他流行语投诉解决方案。
Mule 的优点之一是它可以嵌入到您的应用程序中，并且您的最终工件可以部署在 Webshpere、WLS、Glassfish 等上......甚至不需要显示您嵌入了 ESB。 然后这个 ESB 可以执行所有集成管道（管理连接类型和协议）。 而某些端点可能是您提到的其他集成解决方案。
You mentioned WebSphere, BizTalk, Mule. Each of which has very different characteristics with its good and bad points.
If just integration you are after, I will recommend Mule. I had very good experience with it and more important the architect is non invasive, so you could always migrate to a different ESB or other Buzz word complaint solution.
One the the sweet spots of Mule is that it can be embedded within your application and your final artifact can be deployed on Webshpere, WLS, Glassfish etc... without even showing you embeded an ESB. Then this ESB can perform all the integration plumbing (managing connection types and protocols). Whereas some of the end points could be other integration solution you mentioned.
根据我的经验，这取决于您要解决的问题类型。
根据我的经验，很难在性价比上击败 BizTalk 2006 R2，但它确实意味着使用 Microsoft 技术堆栈。
Websphere MQ 似乎更容易销售给大型企业，并且可能在企业级别得到更多使用。
两者都提供了良好的工具，但实际上取决于您作为开发人员来自定义它以满足客户的要求。
在某些情况下，我发现定制解决方案是最合适的，或者利用 MSMQ 等技术来降低成本。
In my experience it depends on what kind of problem you are tacking.
In my experience it's difficult to beat BizTalk 2006 R2 for bang for the buck but it does imply the use of a Microsoft technology stack.
Websphere MQ seems to be an easier sell to larger corporates and it probably seen greater use at the enterprise level.
Both provide good instrumentation but it's really up to you as a developer to customize this to suit your customer's requirements.
In some cases I've found that a bespoke solution is most appropriate or leveraged technologies such MSMQ to keep costs down.
哇 - 好的 - 会得到一个关于这个的帖子，但会很大。
集成需要得到业务对好处的深入理解的支持 - 整理出一个运营模型 - 因为业务可能实际上需要标准化而不是集成，因为这可能成本高昂 - 这就是大多数 SOA 失败的原因！ 企业架构：通过 IT 推动业务收益
作者：Jeanne W. Ross
如果需要集成，您需要确定集成类型。
速度和性能指标是什么？
我们有一个带有组合应用程序的 .NET SOA，该应用程序使用 BizTalk 2006 和带有业务线应用程序的 Web 服务。 复合端（消耗）的应用程序性能 - 受限于业务应用程序中 Web 服务（及其实现）的速度！ 我们需要不到 3 秒的时间返回结果 - 案例列表。 无法在网络服务中实现，因此我们需要直接进入数据库进行初始搜索。 然后通过网络服务创建案例。 成本影响和维护成为这里的一个问题。
这里的要点是查看规范和业务需求中的性能标准，这将有助于查看您需要执行的集成类型 - Web 服务 (HTTP)、文件删除/ EDI 等
功能上，您需要查看集成所提出的架构中的故障点 - 因为这将导致 SLA/OLA 中的责任链。 您可能需要将集成/故障点包装到您控制的事物中。
关于与业务线集成的类似点是，在集成之前您需要了解多少其他产品？ 是的，Web 服务应该是按合同设计的，但实现常常存在漏洞，您需要了解很多正在发生的事情 - 如果这是一个您无法控制抽象的产品，即使 Web 服务泄漏到您的集成技术（又名 BizTalk）中。
将这两点结合在一起，最好的建议是获得像 BizTalk 这样的集成中心类型 - 将业务应用程序包装在您创建的 Web 服务中 - 这样 BizTalk 端就可以避免抽象泄漏，然后还可以减少故障点因为您已将业务应用程序与集成中心和故障点解耦到单个源而不是编排内部。
SOA 和集成项目中的检测和诊断很难实现！ - 不要让任何光鲜亮丽的销售人员尝试以不同的方式告诉您！ 是的，MOM 和 MOM Ent 可以做到这一点，UniCenter 可以做到这一点。
主要问题是理解插值中的错误（又名打嗝）意味着什么以及如何从中恢复......您最终会遇到消息卡住的情况，您需要了解这对业务流程意味着什么。 您可能会收到一条警报说 - 处理器 100% Ram 100% 编排失败 - 但没有真正的意义。 您必须从一开始就将这些内容设计到解决方案中，并希望能够解决您的故障点。
集成模式的类型以及如何实现它们也需要考虑。
以上是在实时实现中使用 BizTalk 的 .NET SOA 的真实世界视图。 但也正是由于这样的架构限制——BizTalk主要是HUB和SPOKE模式。
查看 Martin Fowler 的企业应用程序模式
有多种方法可以为任务设置皮肤！
其他考虑因素...平台/开发人员语言等。
对我们来说，最重要的因素之一是启动这些东西所需的技能。 我们的 OO 开发人员了解 Java 和 C#，但主要是 C#。 所以我们选择了 MS 堆栈。 但是，当您选择集成类型和产品来管理此问题时，他们将需要更多技能来理解该技术。 但是嘿，这对我们开发人员来说很正常，对吧？ 许多开发人员无论有没有经验都可能会因为 BizTalk 之类的东西而陷入困境！ 范式的巨大转变——部分原因是消息传递的转变而不是代码。
最好的一点放在最后！
整合中可能面临的交易数量可能是所有这一切中最大的因素。 因为这将指导此类事物的模式、故障点和容忍度。
您需要在预期的卷数上选择最合适的。 可以扩展和扩展的东西！ 我们选择 BizTalk 是因为它可以正确地纵向扩展和横向扩展，并且比其他一些方法更好地理解。
如果您没有卷，那么看看是否没有东西来管理它们，并选择没有管理的 Web 服务到 Web 服务类型样式 - 需要将性能和故障理解编码到其中。
如果您使用 .net 3 的 Windows 平台，请查看 WWF/WCF，因为这可以在 Web 服务之间提供帮助 - 现在，在实际平台中可以提供更多帮助来解决所有这些问题，而无需 BizTalk 和其他服务的开销。
希望这可以帮助。
wow - Ok - will get a post on this but will be big.
Intergration needs to be backed up with a big understanding by the business on the benefits - Get an opertating model sorted out - as the business may acutally need to standardise instead of intergrate, as this can be costly - its why most SOA fail! Enterprise Architecture: Driving Business Benefits from IT
Author(s): Jeanne W. Ross
If intergration is needed you then need to settle on type of integration.
What are the speed and performance metrics?
We have a .NET SOA with a Composite Application that uses BizTalk 2006 and webservices with Line of Business Applications. Performance of the application at the composite end (consuming) - is limited to the speed of the webservices (and their implementation) in the line of business application! We need sub <3 second return on results - list of cases. Could not be acheived in the webservices so we need to get go to the database directly for initial search. Then over the webservices for case creation. Cost implications and maintance becomes an issue here.
The point here is to look at the performance criteria in the specs and business requirements this will help in look at the type of integration that you need to do - WebServices (HTTP), File Drop/ EDI etc
Functionally for intergration you need to then look at the points of failure in the proposed architecture - as this will lead to a chain of responisblity in SLA/OLA. You may need to wrapper the intergration/faliure points into things that you control.
On similar point about integration with Line of Business is with how much do you need to know about the other product before you can integrate? Yeah Webservices are supposed to be design by contract but the implementation is often leaky and you need to understand alot about what is happening - and if this is a product that you dont control the abstraction even with webservices leaks into your intergation technology aka BizTalk.
Couple these two points together and you the best advise is to get a intergration hub type like BizTalk - wrapper the line of business applications in webservices you create - so the BizTalk side can be free from leaky abstractions then you also can reduce the points of failure as the you have decoupled the line of business application from the intergration hub and the point of failure to a single source rather than inside an orchestration.
Instrumentation and diagnosics in SOA and Intergation Porjects are hard to acheive! - Dont let any shiney sales person try and tell you differently! Yeah MOM with MOM Ent can do this UniCenter can do blah.
The main problem is understand what the error aka burps in the intergation mean and how to recover from them... You end up with messages stuck and you need to understand what that means to that busienss process. You can get an alert to say - processers are 100% Ram 100% orchestrations have failed - but no real meaning. You have to engineer this stuff in to the solution from the outset - and hopefully into you points of failure.
Types of intergration patterns and how to do them do need to be considered too.
The above is a real world view of a .NET SOA with BizTalk in a LIVE implementation. But it is also due to the architectural limitations of this - BizTalk mainly is a HUB and SPOKE pattern.
Check out Enterprise Application Patterns by Martin Fowler
There are many ways to skin the task!
Other considerations... Platform/Developer Languages etc.
One of the big factors for us was the skills needed to start this stuff. We had OO devs with Java and C# understanding, but mainly C#. So we went for the MS stack. But when you choose the intergration type and the product to manage this they will need more skills in understanding that technology. But hey this is normall for us Devs right? Wrong many developers regardless of there expereince can come unstuck with the likes of BizTalk! Big shift in paradigm - which in part is due to messaging shift rather than code.
Best bit for last!
Numbers of transactions that are likely to be faced in the integration is probable the single biggest factor in all of this. As this will guide what pattern, points of failure and tolarance for such things.
You need to select best on anticpated volumes the right one. Something that can scale up and scale out! We selected BizTalk since it can scale up and scale out correctly and with better understanding than some others.
If you dont have volumes then look at not getting something to manage them and go for a webservice to webservice type style with no management - performance and failure understanding will need to be coded into them.
If your on windows platform with .net 3 take look at WWF/WCF as this can help in webservice to webservice - lots more in the acutal platform now for all these concerns without the overhead of BizTalk and others.
Hope this helps.
我们有甲骨文合同。 所以我们使用 Oracle Stack。 SOA 套件 10.1.3.4。 主要是 BPEL 解决方案，对于简单的转换，我们尝试使用 ESB。
ESB 的故障处理机制很糟糕。 对于 BPEL 有很多方法来处理错误。 我们尝试开发java webservices来连接SOA Suite，我们的主要系统是Oracle EBS系统。 它们通过 SOA Suite 附带的默认 EBS 适配器与遗留系统或其他 EBS 环境进行通信。
我们遇到的问题是缺乏有关 EBS 适配器的知识。 我们在从 EBS 系统接收信息的 BPEL 解决方案中遇到了一些问题。 准备解决方案生产是一项艰巨的工作。
保护我们的网络服务并不是一个大问题。 Oracle 堆栈附带了 Oracle Web 服务管理器。 这样我们就可以保护、记录所有网络服务等。
我们遇到的最大问题是缺乏自己的标准。 让企业感觉他们也可以构建 SOA 解决方案。 我们无法解释他们通过 SOA 解决方案获得的好处。 快点？ 不 ！ 更便宜吗？ 一定不行！ 更简单的解决方案？ 好吧，也许当我们获得良好的可重用服务时……好吧，这个更简单的部分有一个问题：我们如何知道哪些应用程序使用可重用的 Web 服务？
我们需要一个寄存器，可以显示此类信息。 因为我们找不到好的开源解决方案，所以我们正在尝试构建自己的寄存器。 简单的 APEX 解决方案，同样来自 Oracle 堆栈。 ;)
那么有人知道注册此类信息的好产品吗？
we have an Oracle contract. So we are using the Oracle Stack. SOA Suite 10.1.3.4. Mostly BPEL solutions and for a simple transformations we try to use ESB.
The ESB has a bad Fault handling mechanism. For the BPEL there are many ways to handle errors. We try to develop java webservices to connect to the SOA Suite and our main systems are Oracle EBS systems. They communicate to legacy systems or other EBS enviroments through the default EBS Adapters that are shipped with the SOA Suite.
Problems we encountered is the lack off knowledge about the EBS adapters. We encoutered some problems with an BPEL solution that received information from the EBS systems. It was a hell of a job to get the solution production ready.
Securing our webservices isnt't a big issue. With the Oracle stack comes the Oracle Web Service Manager. With that we can secure, log etc. all the webservices.
The biggest problems we encounter is the lack of our own standards. Getting the business to feel that they can also build SOA solutions. We can't explain the benefits they get with a SOA solution. Faster? no ! Cheaper? Hell no! Easier solutions? Well, maybe when we get good reusable services ... well, that easier part has a problem within it: how do we know which applications use the reusable webservices?
We need an register, that can display this kind of information. Because we can't find a good opensource solution, we are trying to build our own register. Simple APEX solution, again from the Oracle stack. ;)
So someone knows a good product to register this kind of information?