基于 EDA 的 SOA 和 NServiceBus：为什么不直接使用 SSIS 包？
我一直在研究 NServiceBus。我喜欢发布-订阅模型的想法，发布者和订阅者之间唯一真正的耦合是消息的语义。现在，我们使用 SQL 复制在软件不同功能区域的数据库之间同步数据。我讨厌这一点，因为我们的私有模式是由订阅者直接耦合的，这使得我们很难进行更改。我认为用 NServiceBus 出版物替换它会很棒，但变化似乎有点剧烈。只使用 SSIS 之类的东西怎么样？我可以使用 SSIS 而不是 NServiceBus 来完成相同的解耦吗？
I have been investigating NServiceBus. I liked the idea of the pub-sub model, and that the only real coupling of the publisher and subscriber is the semantic of the message. Right now we use SQL replication to sync our data between the databases of different functional areas of our software. I hate this because our private schema is directly coupled to by the subscriber, and it makes it difficult to change on our side. I was thinking it would be great to replace this with NServiceBus publications, but the change seems a little drastic. What about just using something like SSIS? Can I accomplish the same decoupling using SSIS instead of NServiceBus?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SSIS 基于元数据，因此仍然需要了解所有数据源和接收器的内部架构。如果每个源/接收器的底层元数据发生变化，您的包也必须更改。您还可以通过 MS 技术进行连接，从而实现平台耦合。由于您正在移动整组数据，听起来您可能没有暂时耦合（系统 A 必须等待系统 B 做出响应）。如果不了解更多有关系统的信息，很难说清楚。最后，SSIS 必须了解交换中所有参与者的物理位置，以便在空间上也实现耦合。
在我看来，如果不将大量 NSB 概念开发到软件包中，您就无法达到与 NSB 相同的水平。这需要在 Sql Broker 上使用 XML 消息或已在 NSB 中解决的类似问题（有关 Sql Broker 传输，请参阅 Github 上的 NSB Contrib 项目）。
SSIS is based on meta-data and therefore will still need to understand the inner schema of all your data sources and sinks. If the underlying meta-data for each source/sink changes your packages will have to change. You also are connecting via MS technologies and are thusly platform coupled. Since you are moving whole sets of data around it sounds like you may not be temporally coupled(system A has to wait for something to respond in system B). It's hard to tell without knowing more about the systems. Lastly SSIS must be aware of the physical locations of all the players in the exchange so you are spatially coupled as well.
In my opinion I don't think you can get to the same place as NSB without developing a lot of the NSB concepts into the packages. This would require using XML messages over the Sql Broker or something to that effect which has already been solved in NSB(see the NSB Contrib project on Github for the Sql Broker transport).