esb

4热度

1回答

我知道has been asked before这个问题，但已经过了两年了，而且事情可能已经发生了变化。另外我还有一些我希望讨论的更具体的要求。我们有几个需要互操作的系统。我们想要使用中介模式和发布/订阅通信模型：有些系统会将信息发布到ESB（中介），然后将信息推送给订阅者。这基本上是我们所需要的，但这可能会涉及一些类型映射并需要与各种协议进行通信。目前我们有WS- *（WCF）服务和REST

1热度

1回答

如何在数据库启动后发送数据库关闭时发送的所有XML消息到PeopleSoft？

我正在使用MULE ESB开展一个项目。在我的工作中应用本方案是从第一个应用程序，我们可以将XML封邮件发送给仁科（其充当第二个应用程序）直接，但它不能保证所有的信息会在人民的最后收到。所以我们决定在第一个和第二个应用程序之间使用MULE。这是一个不错的选择吗？你能有一个更好的选择WRT帮助架构，使仁科接收所有已发送期待着帮助的消息。感谢

1热度

3回答

高度可配置的，高效的ESB/SOA /集成框架

我的计划是开发或使用一个基于Java的集成框架（ESB，SOA等等），与服务交易，有以下限制：服务可以部署在多台机器上，但不一定要在每台机器上都可以使用 a可以单独部署和重新部署服务（使用较新版本） a服务通过以下方式连接到其他服务：：在内存连接（异步/同步）远程处理到其他机器服务的连接的路由逻辑应在飞行可配置的，而无需重新部署或重新启动任何我知道OpenESB接近这些要求，但它需要重

2热度

2回答

PubSub在Java和.Net之间

是否有良好的.Net免费服务总线，允许从Java客户端订阅？我正在使用NServiceBus，我喜欢流畅的API和简单性，但它不支持Java客户端或基于Web服务的WCF集成连接。谢谢！

0热度

1回答

.NET ESB性能

我开始设计我公司的一个电信产品的新版本，并提供负载平衡和可伸缩性我正在考虑某种（.NET开源）ESB。我希望通过避免关系数据库和使用（可能）非馈送到分布式内存缓存（例如Velocity或memcached）的非事务性队列来提高系统的吞吐量。我从来没有在实时系统中使用过这样的体系结构，我担心我在日常开发的简单性中获得了什么，我在吞吐量方面失败了（对于此应用程序而言，它是超-危急）。我只玩过NSe

0热度

1回答

基于软件的负载平衡+一些.NET的ESB工具。有什么选择？（如果有的话）

我需要的软件，将履行下列职能： 1.给一个端点到客户端（从几个服务端点抽象的话） 2.保持传入请求队列几台机器上的多个业务终端之间3.平衡负载 4.这些端点 5.给客户端时，最大CPS或最大消息队列大小达到一些可读误差 6.给一些MSG加工时间预测的控制可用性基于队列大小和已知的服务端点性能这件事应该是基于.NET和WCF友好的。我认为这是负载平衡器和ESB的混合。您可以说出这种类型的现有产

0热度

2回答

使用ESB系统在数据库间复制数据

我在一家小型连锁超市（4家店铺）工作。每家商店都有自己的本地数据库，其中包含每家商店的信息，价格和商店发生的交易。另外，每家商店都需要将这些信息来回复制到一个中心位置。现在我们正在使用一种叫做按照SQLRemote，这是Sybase的SQL Anywhere数据库的一个特点。它有效，但有时会失败，难以管理。值得称道的是，SQLRemote实际上并不是针对这种情况设计的，所以可以说我们错误地使用了

21热度

9回答

BizTalk是ESB吗？

我正在研究架构模式，企业服务总线（ESB）。在阅读这篇文章Enterprise Integration，并且几乎没有任何经验时，我在想BizTalk是ESB还是仅仅是EAI（Hub/Spokes或Bus）？我发现这个NServiceBus and Biztalk，描述BizTalk作为一个中央消息代理。考虑其他ESB框架（NServiceBus和Rhino服务总线）。这些框架没有处理消息的中心

2热度

1回答

在同一台服务器上安装不同版本的Mule ESB

问题 - 可以在同一台服务器上部署不同版本的Mule（如Mule 2.0和2.2.0）吗？它们将用于不同的应用程序。因为它会有冲突吗？在做这些事情之前，是否应该先照顾任何先决条件您是否预见到此潜在风险？谢谢:)

2热度

3回答

SOA/ESB难题

对不起，这个问题我一直在研究一段时间，这让我非常沮丧。我觉得在今天这个时代，我们有一百万种实现服务的方式，它们都是跨平台（SOAP）并且易于构建（感谢.NET，Java和其他框架）。然而，这些技术已经在社会各界的5 - 10年，但我们（至少我）不断地与同样的问题所困扰：识别（跟踪服务） - UDDI;例如，本月必须提醒同事3次服务所在的位置，尽管事实上有一个讨论该服务的wiki和一个生活在我们保