1
7
的确,JCA 似乎 最适合你的技术。已经有了很好的论据,即可移植性、标准化接口、连接池和事务支持。别忘了安全。 使用WebSphereProcessServer,适配器可以作为SCA服务公开,如果这对您很重要,那么它可以带来很多好处。 另外,一些开发工具对开发和测试JCA连接器有广泛的支持。 另一个好处是(经验丰富的)Java EE管理员和JavaEE开发者(应该)知道标准,所以管理和开发应该易于简化。 但最后,您必须根据项目的范围、项目的未来计划或公司的政策,找出实现JCA的原因。 |
2
5
简短的回答:我认为选择JCA对其他技术没有好处,我认为这是一个缺点,因为您需要JavaEE容器。 长回答: 我对这些JavaEE标准持怀疑态度已有一段时间了。我看不出有什么吸引力 技术的 因为使用了更好的开源实现,所以不再使用完整的JavaEE服务器了。 每一个 提供的功能。当我从“企业解决方案”转移到“企业解决方案”或从“企业解决方案”转移到“企业解决方案”时,由于实现不兼容,我被咬了好几次。 JCA的想法正在这里浮出水面,我正努力尝试 apache camel 或 spring integration 相反。我完全赞成在任何地方都可以使用的开源实现。还有很多事情。检查 this list of components . 当然,可能比JCA已经开发的要小,但是每一个位都是开源的,并且都在一个位置上。此外,我相信文档更简单、更完整。集成的迫切需要一个强大的SPI,它具有大量的开源、真实的实例,以相同的方式开发,并且可以在同一个地方找到。 我讨厌这种消极情绪,但我不喜欢功能齐全的应用服务器。例如,我会选Tomcat和Terracota 任何一天 超越了其他“进取”产品,就像我在JCA之前和骆驼一样,直到JCA的需求得到证明。我不喜欢Java委员会告诉我应该如何开发自己的应用程序,因为我不信任它们。我相信这是我的最佳利益时,该软件可以工作一样容易在JavaSE/RCP,如在JavaEE环境或在纯servlet容器。 |
3
4
我刚刚开发了一个入站资源适配器,用于GPS设备通过专有协议进行通信。这没那么麻烦,尽管我觉得开发一个外向的可能需要更多的工作。JCA最糟糕的是缺少文档。所有的书籍和文章似乎都有相同的愚蠢例子。 我最满意的是便携性。一旦您编写了适配器,就可以将RAR(资源适配器存档)插入到任何应用服务器中,以提供部署的应用程序与RA支持的EIS通信的能力。或者您可以将RAR捆绑到战争/耳朵中。 |
4
1
这些好处主要是为了那些希望将连接器卖给专有后端系统的供应商,以便与任何应用服务器一起使用,对于那些希望能够在连接器中掉落的客户,而不必担心它是否只在WebLogic上工作,而不是WebSphere等。 注意,JBoss已经决定将一些东西放到JCA中,例如JDBC连接通过JCA。 您未来的客户机代码将有一个标准化的接口、一些池和事务支持等,但重要的是要看到更大的前景;也就是说,好处不是针对您和您的一个项目,而是针对由许多应用服务器、许多后端系统、许多连接器等组成的软件生态系统。在。 |
5
0
听起来很适合 JBI 带有绑定组件的容器。 Discussion JCA与JBI。 |