Java EE - получить информацию о ячейке / узле из класса - PullRequest
Новая
       26

Java EE - получить информацию о ячейке / узле из класса

0 голосов
/ 25 февраля 2011

Мне нужно взаимодействовать с C / C ++ из приложений Java Enterprise. Я хотел бы написать класс, который сможет собирать информацию об узлах и ячейках, возможно, любую дополнительную информацию о том, где развернуто приложение, поэтому я могу, начиная с 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, собственными двоичными исполняемыми файлами C / C ++ (.exe и т. Д.), А также с другими приложениями, вызов которых поступает из (в основном) полностью закрытого приложения. Этот источник предоставляет способы гарантировать, что приложение, вызывающее его, на самом деле является доверенным приложением (звучит похоже на подписание кода, но я могу заверить вас, что то, что он делает с этими исходными файлами, намного сложнее).

Я пытаюсь расширить эту функциональность в нашей архитектуре Enterprise Java, и для этого мне нужно иметь возможность вернуться туда, откуда поступил вызов, даже если это означает просто перейти к развернутой WAR или даже к EAR, в который было упаковано приложение, поэтому я могу использовать исходные файлы с исходным кодом C / C ++. Поэтому, если вызов поступил из приложения A, а приложение было развернуто в App_A.EAR, я хотел бы получить эту информацию и вызвать C / C ++, проследить до этого EAR и поработать с ним. Если это звучит странно, я прошу прощения, но я (из-за поведения) опускаю большую часть того, для чего используются файлы (.exe или JAR / WAR / EAR).

Еще раз спасибо за любую помощь, которую вы могли бы оказать!

* РЕДАКТИРОВАТЬ *

Чад

1 Ответ

1 голос
/ 27 февраля 2011

У меня есть три проблемы, которые вы, возможно, захотите рассмотреть, прежде чем я получу ответ:

  1. Почему вам нужно найти базовый файл jar / ear / war / class?Вы беспокоитесь о запуске вредоносного кода?Если это так, то я настоятельно рекомендую вместо этого использовать подпись кода и безопасность политики .Это правильные инструменты, которые встроены в платформу.
  2. Серверы приложений, а также корпоративные приложения могут использовать пользовательские загрузчики классов, которые могут хранить файлы jar или классов так, чтобы их не было сразу доступно.другие приложения.Я не могу вспомнить ни одного примера такого, но имейте в виду, что Java не навязывает и не предписывает каким-либо образом способ, которым загрузчики классов отображают ресурсы в физические файлы, если они делают это последовательно.По замыслу интерфейс для загрузки классов и ресурсов преднамеренно отделен от особенностей базовой операционной системы.В частности, реализации корпоративных приложений могут стимулировать беспорядок со способом хранения jar-файлов, если это помогает ускорить и управлять управляемыми ресурсами загрузчика классов.
  3. Для кластерных сред вам, вероятно, не повезло.Все части, которые облегчают связь между различными узлами в кластере, не предписаны и не регулируются спецификацией Java Enterprise Edition.У конкретного поставщика могут быть проприетарные интерфейсы, которые позволяют вам определить, с каким узлом взаимодействует удаленный интерфейс, но поскольку цель кластеризации и балансировки нагрузки состоит в том, чтобы сделать его прозрачным для приложения и его клиентов, вы, вероятно, еще менее вероятнополучить доступ к этой информации.

Хорошо, ответим.Возможно, вы захотите попробовать посмотреть Class.getProtectionDomain и ProtectionDomain.getCodeSource: 

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

Остерегайтесь того, что вызов getProtectionDomain может вызвать SecurityException в зависимости от действующей политики безопасности.

Обновление:

Похоже, ваше программное обеспечение борется с security и проблемами доверия,Но вам не нужно проверять двоичный код каждый раз, когда вы запускаете код.Вы можете достичь того же уровня доверия с подписью кода .Как? Вы подписываете код.

  1. Когда внешнему приложению необходимо взаимодействовать с вашей библиотекой, запросите копию двоичного кода для проверки.
  2. Когда выЕсли вы удовлетворены результатом, подпишите код, используя собственный закрытый ключ.
  3. Затем настройте политику безопасности, которая будет позволять запускать только приложения, подписанные вами.

Снапример, RSA и 2048-битный ключ, или даже больший размер ключа, практически невозможно заменить какую-либо часть подписанного кода известными сегодня атаками на RSA.

Эта стратегия требует, чтобы вы управляли сервером приложений иJVM, на которой он работает.Если ваши проблемы с доверием выходят за рамки этого, вам, вероятно, нужно подумать о том, чтобы назначить сервер приложений с открытым исходным кодом, где можно проверить исходный код и подписать двоичные файлы, и, в конечном счете, саму JVM.

Не зная,конкретные сведения о вашей архитектуре и настройке я все же рекомендую использовать функции безопасности, встроенные в платформу Java.

...