Java EE - 从类获取单元/节点信息

Question

我需要从 Java Enterprise 应用程序与 C/C++ 进行交互。我想编写一个能够收集 Node/Cell 信息的类，可能还有有关应用程序部署位置的任何其他信息，因此我可以从 C++ 追溯到调用来源的文件系统中的 JAR(权威)。是否有一个特定的 Java 库可供我使用来提供有关应用程序的此类信息？理想情况下，会发生的是:(我们称之为 EnvProvider)

1. Java 应用程序调用 EnvProvider
2. EnvProvider 收集有关调用它的 Java 应用程序的信息
3. EnvProvider 调用包装的 C++(也许是 CORBA、SOAP？)并传递此信息
4. C++ 将文件系统追溯到调用应用程序，以检查声称的应用程序调用来自的实际 JAR 文件。

这听起来微不足道(这里仅概述了 4 个步骤)，但从我迄今为止的研究来看，似乎没有好的方法可以从 Java 应用程序本身获取有关 Java 应用程序的足够信息。我所说的“足够”信息，是指足以为 C++ 提供足够的信息来遍历文件系统并找到已部署的 EAR、JAR、WAR。

如果您能提供任何信息，我们将不胜感激!

问候

乍得

* 编辑*

金，谢谢您的回复。让我解释一下为什么我需要获取这个特定的跟踪。

我正在开发/使用一个用 C/C++ 编写的加密库。它们是我的前任在这里(我工作的地方)编写的，并且经过了很好的测试。然而，它们提供的不仅仅是加密，而且其中包含的算法是专有的，需要保持安全。这排除了在 Java 中实现相同功能的可能性，因为 Java 太容易被反向编译了。事实上，我的前任不遗余力(理所当然地)混淆了 C/C++ 源代码。这些库可以与 Shell、 native C/C++ 二进制可执行文件(.exe 等)以及其他应用程序(其中调用来自(大部分)完全包含的应用程序)配合良好。该源提供了确保调用它的应用程序实际上是受信任的应用程序的方法(听起来类似于代码签名，但我可以向您保证它对这些源文件所做的事情要复杂得多)。

我正在尝试将此功能扩展到我们的企业 Java 架构中，为了做到这一点，我需要能够返回到调用的来源，即使这意味着只是进入已部署的 WAR 甚至是应用程序打包在 EAR 中，因此我可以将源文件与 C/C++ 源一起使用。因此，如果调用来自应用程序 A，并且应用程序部署在 App_A.EAR 中，我想获取该信息并调用 C/C++，追溯到该 EAR 并使用它。如果这听起来令人困惑，我深表歉意，但我(作为行为问题)遗漏了文件(.exe 或 JAR/WAR/EAR)的大部分用途。

再次感谢您提供的任何帮助!

* 编辑*

乍得

Answer 1

在我给出答案之前，您可能需要考虑三个问题:

1. 为什么需要找到底层的jar/ear/war/class文件？您担心运行恶意代码吗？如果是这样，那么我强烈建议使用 code signing和 security policies反而。这些是平台内置的适当工具。
2. 应用程序服务器以及企业应用程序可能会使用自定义类加载器，这些加载器可以以其他应用程序无法立即访问的方式存储 jar 或类文件。我不记得任何这样的例子，但请记住，Java 不会强制或强制类加载器如何将资源映射到物理文件的任何一种方式，只要它们一致地执行即可。根据设计，用于加载类和资源的接口(interface)故意与底层操作系统的特性分离。特别是，如果 JAR 文件有助于加速和管理类加载器管理的资源，那么企业应用程序实现可能会有动力去扰乱 JAR 文件的存储方式。
3. 对于集群环境，您可能不走运。 Java Enterprise Edition 规范并未规定或管理集群中不同节点之间通信的所有部分。特定供应商可能拥有专有接口(interface)，允许您确定远程接口(interface)正在与哪个节点通信，但由于集群和负载平衡的目标是使其对应用程序及其客户端透明，因此您可能更不可能访问此信息。

好的，开始回答。您可能想尝试查看 Class.getProtectionDomain和 ProtectionDomain.getCodeSource :

ProtectionDomain protectionDomain = someObject.getClass().getProtectionDomain();
SourceLocation sourceLocation = protectionDomain.getCodeSource();
URL url = sourceLocation.getLocation();

请注意，调用 getProtectionDomain 可能会导致 SecurityException取决于有效的安全策略。

更新:

听起来您的软件正在与 security 作斗争。和信任问题。但是您不必每次运行代码时都检查二进制代码。您可以通过 code signing 获得相同级别的信任。如何？ 您签署代码。

1. 当外部应用程序需要与您的库交互时，请索取二进制代码的副本以供检查。
2. 当您对结果感到满意时，请使用您自己的私钥对代码进行签名。
3. 接下来，设置一个安全策略，仅允许您签名的应用程序运行。

例如RSA 和 2048 位 key ，甚至更大的 key 大小，实际上不可能用当今已知的针对 RSA 的攻击来替换签名代码的任何部分。

此策略要求您控制应用程序服务器及其运行所在的 JVM。如果您的信任问题超出了这个范围，您可能需要开始考虑强制使用开源应用程序服务器，您可以在其中检查源代码并签署二进制文件，并最终检查 JVM 本身。

在不了解有关您的架构和设置的具体细节的情况下，我仍然建议利用 Java 平台内置的安全功能。