pmp访谈法和焦点小组区别
由Mark Fisher，Jonas Partner，Marius Bogoevici和Iwein Fuld撰写的《 Spring Integration in Action》一书涵盖了Spring Integration框架 ，该框架提供了基于Spring编程模型的著名企业集成模式的实现。 它在基于Spring的应用程序中启用轻量级消息传递，并使用声明性适配器支持应用程序集成。
作者以异步消息传递体系结构的核心组件（消息，通道和消息端点）开始对Spring Integration框架的讨论。 正如他们在第一章中所说的那样，Spring Integration是“企业集成模式满足控制反转”的地方。 通过示例应用程序和代码示例详细讨论了企业集成模式以及Spring Integration框架如何实现这些模式。
该书还涵盖了Spring Integration为使用电子邮件批处理适配器和Web适配器，Web服务以及使用Spring Batch框架进行的文件批处理提供的支持。 为了完成讨论，作者讨论了使用JMX监视和管理消息传递组件。 最后，本书中的讨论以“测试”主题结束，该主题涉及如何通过模拟服务来测试异步系统和消息传递组件。
InfoQ与Mark Fisher和Iwein Fuld谈了有关Spring Integration框架及其优势和局限性的书。
InfoQ：使用应用程序集成作为基于云的服务的趋势正在增长。 您能否谈谈“集成即服务”的新概念，以及Spring Integration框架如何提供帮助？
Iwein： Spring Integration本身不是什么“服务”。 这是一件好事。 作为开发人员，您有兴趣与其他* aaS API集成，并且在混合中使用类似ESB的服务通常并不能简化事情。 在服务体系结构中使用Spring Integration很容易，为什么不能在云中使用Spring Integration。 SI的优势在于集成，而不是服务。 就是说，Cloud Foundry对Spring应用程序（因此对Spring Integration）具有本机支持，并且提供Spring Integration支持的服务（例如RabbitMQ，Redis，MongoDB和关系数据库），因此可能性和示例唾手可得。
InfoQ：NoSQL数据存储是否比关系数据库在消息传递体系结构中使用更好的选择，例如，将消息存储在队列通道或消息存储中？ 在消息传递应用程序中使用NoSQL数据库实现持久性的优缺点是什么？
Iwein：如果您使用的是NoSQL存储，通常对于写操作和简单的“按键”查询而言，优化效果更好。 这更适合消息传递模型。 也就是说，针对这种用法优化关系数据库并不难，因此使用NoSQL存储库的选择实际上不应由选择Spring Integration作为消息传递框架来驱动。
马克：而且，NoSQL存储并不是万能的，因此，更有趣的讨论是关于Spring Integration通过为多个不同的NoSQL存储提供适配器来支持各种用例。 例如，您可以使用我们在2.2版中添加的通道适配器，以消息驱动的方式轻松地在Redis ZSET中更新乐谱。
InfoQ：大数据，数据挖掘和数据处理近来引起了人们的广泛关注，以帮助他们高效有效地处理和分析不同类型的业务数据。 Spring Integration和Spring Batch框架如何适应大数据空间？
Iwein：如果您希望快速获得一次性代码，Spring Integration和Spring Batch可能不适合您。 但是，如果您想要一个可维护的解决方案，那就可以了。 Spring产品系列在使用寿命长的应用程序中大放异彩，在这些应用程序中，可维护性比快速上市时间要重要。 在大数据空间中，情况非常不稳定。 通常，解决方案旨在快速完成，获得投资回报并被丢弃。 如果这适用于您的解决方案，则跳过Spring Integration是明智的。
马克：但是，我们开始研究3.0版，其中的主题之一是大数据支持。 这将不仅包括用于HDFS的适配器以及与Spring for Apache Hadoop项目的无缝集成，而且还可能包括将干扰器模型应用于我们的套接字级别连接工厂的功能。 加上Spring Integration的低开销，应该可以满足许多大数据解决方案的吞吐量需求。 同样，我们在探索“现实世界”大数据场景时注意到的一件事是，要解决的最终问题通常是集成问题：组合来自多个来源的数据，定义跨不同系统的流程，创建具有多个处理步骤的管道，等等。上。 显然，在那里可以使用与“经典”企业集成相同的工具和框架。
InfoQ：安全性是企业应用程序开发的重要方面，尤其是在集成用例中。 您能否讨论Spring Integration提供的用于保护各种消息传递组件的支持？ 这方面的最佳做法是什么？
Iwein：消息传递中的安全性是在传输级别或在消息级别或同时在这两者上完成的。 Spring Integration设法在两个方面都回避这些问题是很酷的。 由于SSL https下面只是http，因此SI无需知道。 在消息级别，Spring Integration委托Spring WS的安全组件。 这些很好，所以我们再次躲过了难关。 我认为，如果您关心安全性，则可以确保消息的安全。 这样就可以确保最终接收方和最终发送方之间的信任是干净的，而不是对整个网络拓扑负责。 许多组织走了一条不同的路，完全忽略了消息级别的安全性，因为“在传输级别上一切都得到了照顾”。 就像假设安装操作系统的人没有安装键盘记录程序那样愚蠢。 这是一种广泛的做法。 我知道安全性方面的最佳实践始终是保持智慧，而不是信任最佳实践。
马克： Spring Integration确实提供了一个Channel Interceptor，它仅委托给Spring Security授权管理器，但是同样，它通常根据传输级别上可用的信息来检查SecurityContext。
InfoQ：您在书中讨论了有关如何测试消息传递应用程序中各种组件的测试技术。 您能否谈谈其中的一些技术，以及Spring和Spring Integration框架如何使测试消息传递组件变得更加容易？
Iwein：第18章对此非常清楚。 在进行SI测试支持时，我最着眼的是，当您试图弄清楚多线程应用程序的工作方式时，使用调试器是一个非常糟糕的主意。 弄清楚之后，我停止使用调试器，而是继续遵循自己的建议来修复测试和日志记录。 令人困惑的是浪费了多少时间在调试器中学习有关代码的知识，然后一经发现就将其丢弃。值得一提的另一件事是，大多数并发问题都可以通过精心设计的测试用例引发。 马克和我有些深夜，我们无法重现彼此的问题，但是如果您愿意漫步，总有一种确定性测试案例的方法。 与一般的功能测试相比，您应该准备花更多的时间，因为这些测试将在您需要时挽救您的生命。
InfoQ：EIP模式的局限性是什么？或者集成架构师和开发人员在应用程序中使用这些模式时应牢记什么？
Iwein：在书中写东西的问题是，您没有被迫检查它们是否足够明确，无法被解析并编译成真实代码。 我们在本书中曾多次为此而苦苦挣扎，但在实施SI时我们也为EIP本书而苦恼。 在设计体系结构时，架构师应记住，代码的外观会有所不同，而开发人员应记住，新兴的体系结构必须与底层代码一样干净。 EIP更像是一个入门指南，即使这些模式在代码上与本书中看起来有所不同，但正常工作的软件还是要胜过它。
马克：此外，在设计模式方面，通常最重要的是语言。 这就是开发人员可以在所学内容与给定API中的显示方式之间建立联系的原因。 因此，每当为属性或配置属性找到正确的名称时，我们都会查阅EIP书，并希望从那里使用的词语中获得启发。 一致性也很重要； 因此，每当面临将特定EIP映射到我们的API的挑战时，我们都会尝试遵循类似的技术并使用相似的术语。
InfoQ：您能否谈谈企业应用程序集成领域的新兴趋势？
Iwein：主要趋势是（仍然）REST。 既然JavaScript框架和浏览器已赶上规范，那么Http才开始发挥其全部潜能。 我现在几次看到的另一个有趣的趋势是，通过远离既定的工作方式来优化效率。 这对于移动设备，不稳定的网络很有用； 但也适用于不太可能的设备，例如家庭能源测量设备。 在这种情况下，Spring Integration的TCP / UDP适配器可能会派上用场。
马克：除了REST API外，通过Web套接字和更高级别的抽象（例如SockJS）进行基于Web的消息传递也越来越流行。 这些技术为客户/服务器关系发生巨大变化的应用程序集成开辟了一个全新的世界。 这是我们对Spring Integration 3.0路线图关注的另一个领域。
作者还讨论了通用和最佳实践中的应用程序集成。
Iwein：我不赞成使应用程序复杂化，即使这样做是通过重用我的代码来完成的。 许多开发人员认为他们将需要异步处理，因此他们使用SI，Camel或Akka。 最后，经常发现没有做任何认真的测量来查看单线程解决方案是否可以将其切断。 不要那么傻，因为您可以使用很酷的技术。 不要误会我的意思，SI很棒，但是如果您能在没有并发的情况下走开，那么您总会过得更好。
马克：那就是说，当消息驱动模型*满足您的应用程序需求时，Spring Integration隐藏了大多数复杂性。 为了获得最佳性能，您仍然需要了解如何配置线程池和触发器，但是无需编写处理任务调度和异步调用的代码。 相反，与任何Spring应用程序一样，您专注于自己业务域的POJO。 这也意味着您的代码以易于测试的方式与基础架构脱钩，这是我们可能都同意的“最佳实践”。
pmp访谈法和焦点小组区别
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
