从非托管环境访问 Java 连接器架构 (JCA)
我们一直在使用 JCA 与 WebSphere 内部的低级网络资源进行交互，但是我们需要能够从 Tomcat 外部访问相同的网络资源（即不在托管环境中）。网络通信和协议布局非常冗长，因此我们宁愿不复制/粘贴几千行代码（然后必须单独维护它们）。
通过阅读 JCA 规范，据说有一些支持在非托管环境（例如 Tomcat）中执行代码。不幸的是，我不知道这些接口应该做什么，或者如何从托管环境外部调用它们（规范非常模糊）。
是否有任何实现示例展示如何修改 JCA 以使其可在非托管环境中使用？
谢谢！
We have been using a JCA to interface with a low-level network resource from within WebSphere, however we have a requirement to be able to access the same network resource externally from Tomcat (i.e. not in a managed environment). The network communication and protocol layouts is very verbose, so we would rather not copy/paste several thousand lines of code (and then have to maintain them separately).
From reading the JCA spec, there is supposedly some support to execute the code in a non-managed environment (such as Tomcat). Unfortunately, I have no idea what the interfaces are supposed to do, or how to call them from outside a managed environment (the spec is pretty vague).
Are there any implementation examples out there that show how to modify a JCA to be usable in a non-managed environment?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们有类似的情况，我们开发了一个连接器来访问外部 WebDav 存储，并且也希望从独立应用程序（非托管）中使用它。
我确实相信，最简单的方法是在设计级别解决这个问题，并以连接器的核心逻辑与 JCA 无关并且可以轻松重用的方式组织代码。然后，您可以使用 JCA 特定的代码来包装它，将连接器公开给 AS。它甚至可能打包在两个 jar 中——这至少是我们选择的解决方案（但我们将所有内容打包在一个 .jar 中）。
否则，JCA 连接器是以下三方之间的“粘合剂”：
应该可以通过必要类的轻量级实现来模拟 AS，然后直接使用 JCA 连接器。
AS 对于 JCA 连接器的一项主要工作是管理连接池，据我所知，您应该实现的相应接口是
ConnectionManager。JCA 连接器接收对
ConnectionManager的引用，但实现是特定于 AS 的。编写一个提供基本池化（或根本不池化）的轻量级实现听起来是可行的。我曾经写过一个连接分配的序列图机制。也许你会发现它很有用。另一个接口是 ResourceAdapter，您可以在其中定义启动/关闭，但手动调用很容易。
（可能不止于此，当然这取决于您的 JCA 连接器使用的内容。例如，如果它使用
Work和WorkManager，那么它就变成如果连接器是事务性的，则模拟要复杂得多。但它似乎不是你的情况。）否则，我认为 Spring 对 JCA 有一些支持，可能值得看看他们是如何做到的。 。
您能提及您所指规范的具体部分吗？
We had similar case, where we developed a connector to access external WebDav storage, and wanted to use it also from a stand alone application (non-managed).
I do believe that the easiest way is to solve this at the design level, and organize your code in a way that the connector's core logic is JCA-agnostic and can be reused easily. Then you can wrap this with JCA-specific code that exposes the connector to the AS. It could probably even be packaged in two jar -- That's at least the solution we choose (but we packaged all in one .jar).
Otherwise, a JCA connector is the "glue" between the following three parties:
It should be possible to simulate the AS with a lightweight implementation of the necessary classes, and then use the JCA connector directly.
One main job of the AS with respect to a JCA connector is to manage the pooling of connections, and from what I remember, the corresponding interface that you should then implement is
ConnectionManager.The JCA connector receive a reference to a
ConnectionManager, but the implementation is AS-specific. Writing a lightweight implementation that provides rudimentary pooling (or no pooling at all) sounds feasible.I had written once a sequence diagram of the connection allocation mechanism. Maybe you will find it useful. Another interface is
ResourceAdapterwhere you define the startup/shutdown, but that's easy to invoke manually.(There is probably a bit more than that, and it of course depends on what your JCA connector uses. For instance, if it use
Workand theWorkManager, then it becomes a lot more complicated to mock. Same remark if the connector is transactional. But it doesn't seem to be your case.)Otherwise, I think that Spring has some support for JCA, it may be worth having a look how they did it.
Can you mention the specific part of the spec you are referring about?