Дисковое хранилище в приложении Java EE - PullRequest
5 голосов
/ 05 июня 2011

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

Я не хочу испытывать трудности интеграции с полной базой данных для этого небольшого количества данных.

Существует ли стандартный способ доступа к файловой системе и стандартной папке, в которой веб-приложения могут хранить свои данные на диске, кроме использования базы данных?

Примечание:

Я не использую EJB. Это веб-приложение, использующее сервлеты.

Ответы [ 4 ]

3 голосов
/ 05 июня 2011

Используйте простую базу данных на основе Java, такую ​​как HSqlDB или h2.Установка не будет такой сложной по сравнению с тяжелой БД.Основное преимущество, которое это даст вам, - это управление одновременными обновлениями, которые вам придется кодировать самостоятельно, если вы используете прямой доступ к файлам.

3 голосов
/ 05 июня 2011

Вы можете рассмотреть возможность использования предпочтений API для хранения этих данных - он также доступен в Java EE.

2 голосов
/ 05 июня 2011

Доступ к файлам всегда был спорным действием в приложениях на основе EJB из-за ограничений, налагаемых на поставщиков компонентов в спецификации EJB.Часть соответствующей спецификации находится в разделе, озаглавленном «Ограничения программирования», и в нем говорится о доступе к системе регистрации:

Корпоративный компонент не должен использовать пакет java.io для доступафайлы и каталоги в файловой системе.

Это довольно конкретное утверждение и сопровождается кратким объяснением того, почему это так.

Файлсистемные API не подходят бизнес-компонентам для доступа к данным.Бизнес-компоненты должны использовать API менеджера ресурсов, такой как JDBC, для хранения данных.

Хотя это объяснение выдвигает на первый план ключевую причину неиспользования файлового ввода-вывода, я думаю, что это намного больше,Однако, хотя это хорошо известное ограничение, на самом деле поиск дополнительной информации об этом занимает много времени.Итак, в поисках знаний я немного покопался и нашел следующие причины, по которым файловый ввод-вывод является «плохой вещью» TM.

Мантра WORA в Java и J2EE означает, чтона самом деле быть системой регистрации доступа.Я видел различные комментарии, в которых говорилось, что сервер J2EE может работать на каком-либо устройстве, которое не имеет системы регистрации, или сервер приложений не имеет доступа к регистрации, потому что он развернут, например, на сервере базы данных.Хотя это и есть веская причина, я не думаю, что это относится к большинству проектов.Доступ к файлам не транзакционный.Да, обычно файлы не являются транснациональными ресурсами, и при построении корпоративных систем вы обычно хотите быть уверенными в том, что некоторая информация была правильно и точно сохранена, следовательно, используется реляционные базы данных и тому подобное.Доступ к файловым системам - потенциальная дыра в безопасности.Если мы посмотрим, как осуществляется доступ к другим ресурсам (например, JDBC DataSources, JMS Topics и т. Д.), То это обычно через JNDI.Чтобы гарантировать, что только авторизованные стороны могут получить к ним доступ, у нас обычно есть такие ресурсы, защищенные каким-либо механизмом аутентификации, будь то комбинация имени пользователя / пароля или SSL-сертификат.Проблема с файловыми системами заключается в том, что они гораздо более открыты и доступ к ним сложнее контролировать.Одним из решений является блокировка доступа к файлу через операционную систему, а другим является использование модели безопасности Java для ограничения доступа только к определенной части диска.Если вы собираетесь получать доступ к системе регистрации из своих бизнес-компонентов, то блокировка доступа поможет сделать систему более защищенной и устойчивой к атакам.Итак, как нам получить доступ к файлам из EJB?Многие люди выступают за использование промежуточного класса Java для завершения доступа к файлу, полагая, что спецификация EJB запрещает доступ только из самого класса бина.Это правда?Я не убежден, потому что применяются все те же причины.Сама спецификация представляет ответ, и этот ответ заключается в том, чтобы использовать менеджер ресурсов, чтобы мы могли рассматривать доступ к файлам как безопасный транзакционный объединенный ресурс.Одной из таких реализаций является адаптер *1015* J2EE Connector Architecture (JCA), который вы пишете, развертываете и настраиваете для доступа к вашей системе хранения.Фактически, некоторые поставщики уже создали JCA-адаптеры для доступа к плоским файлам, и они особенно полезны, если вам нужен доступ к выходам устаревших систем мэйнфреймов.

Конечно, многие типы доступа к файлам можно обойти. Например, информация о конфигурации может быть помещена в LDAP, JNDI, базу данных или даже файлы свойств, доставленные в ваши файлы JAR, которые загружаются как ресурс через загрузчик классов. В тех случаях, когда требуется доступ к файлам, другие решения включают загрузку файла через контейнер сервлетов, его отправку на уровень EJB посредством обмена сообщениями, загрузку файла с веб-сервера через соединение через сокет и т. Д.

Это все обходные пути для ограничения программирования, но в конце дня я думаю, что вы должны быть прагматичными. Многие проекты используют доступ к файлам из уровня EJB, и их решения работают. Хотя спецификация EJB накладывает ограничение, в действительности многие поставщики предпочитают не применять это, то есть использование пакета java.io для доступа к файлам возможно. Какое бы решение вы ни предложили, в идеале вы должны помнить о спецификации. Он поможет вам создавать переносимые и обновляемые приложения, но следует применять прагматизм. Надеемся, что в будущей версии спецификации EJB этот вопрос будет рассмотрен более подробно, и этот спор уйдет в прошлое.

Кредит за вышеуказанное идет на: Саймон Браун

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

1 голос
/ 05 июня 2011

Существует ли стандартный способ доступа к файловой системе и стандартная папка, в которой веб-приложения могут хранить свои данные на диске, кроме использования базы данных?

Существует java.io.File API, но спецификации сервлета или Java EE не предоставляют стандартную директорию , в которой вы можете сохранять файлы в течение длительного времени. В лучшем случае атрибут javax.servlet.context.tempdir может использоваться для определения местоположения каталога временных файлов из ServletContext.

.

Обоснование отказа от поддержки стандартных файловых каталогов связано с невозможностью предсказать, сможет ли контейнер получить доступ к файловой системе. Ваш контейнер может запускаться со встроенного устройства в первую очередь, которое может полагаться на SAN или другую удаленную файловую систему для сохранения файлов.

Кроме того, использование файлового API в EJB-компонентах не одобряется из-за нетранзакционной природы файловых систем, поэтому аналогичная концепция рабочих каталогов и файлов отсутствует.

...