вторник, 13 октября 2009 г.

Java с высоты .Net или наоборот. Глава 1. Основные проблемы. Часть первая

Это вторая статья из цикла "Java с высоты .Net или наоборот". Первая тут.

Сложившиеся обстоятельства заставляют меня разрабатывать распределенное приложение на Java. Что я больше всего люблю из .Net для реализации распределенности? Правильно, веб-сервисы.

В .Net веб-сервисы создаются очень просто. Имеется отличная поддержка сериализации, имеется хороший прокси генератор, в конце концов с выходом WCF, мы получили еще и хороший набор конфигурируемых параметров.

Как же дела с веб сервисами обстоят на джаве?

Первое что бросается в глаза это большое количество реализаций веб сервисов. ДА! Именно реализаций! Т.е. в дотнете мы уже и забыли что веб сервисы можно реализовывать по другому. Microsoft дали нам инструмент и мы им пользуемся с большим удовольствием. Тут же тебе реализаций несколько. Я "пощупал" две реализации, первая это Axis, вторая Jax-WS.

Говоря о веб сервисах нельзя ни сказать что же такое JavaEE. По своей сути JavaEE это не набор каких то библиотек, как я думал сначала, а это просто напросто спецификация которая описывает то что должно быть на серверной стороне. А реализаций JavaEE спецификации очень много. Каждая реализация JavaEE - это сервер приложений. Сервер приложений это сервер, в котором будут выполняться ваши приложения. Этот сервер содержит набор библиотек реализующих JavaEE. Я понимаю это так. В Вики по этому поводу написано следующее:
Сервер приложений J2EE (часто называемый J2EE-контейнер) — это реализация системы в соответствии со спецификацией J2EE, обеспечивающая работу модулей с логикой конкретного приложения.

Вроде я правильно понимаю. Итак серверов приложений есть много. Каждый что то делает по своему.

Реализация JavaEE должна в себя включать минимум следующие вещи:
1. EJB - спецификация технологии написания и поддержки серверных компонентов, содержащих бизнес-логику;
2. JMS — сервис доставки сообщений между компонентами и серверами;
3. управление ресурсами (доступ к СУБД, файловой системе, почтовому серверу и т. д.);
4. безопасность и защита данных;
5. поддержка транзакций (в том числе и распределённых, двухфазных).
7. поддержка веб-сервисов.
8. JSF

Я же пробовал следующие сервера приложений:
1. Glassfish (реализация от SUN). Использовал на нем реализация веб-сервисов Jax-WS.
2. Tomcat. В связке с AXIS.

Для первого я использовал NetBeans, для второго Eclipse.

Что из этого вышло напишу чуть позже.

9 комментариев:

  1. > "1. EJB-контейнер, который поддерживает автоматическую синхронизацию Java объектов с базой данных"

    Не совсем так, EJB - это объекты для построения бизнес-логики. Они могут быть доступны для вызовов внутри сервера приложений (из сервлетов/JSP/etc), для внешних вызовов (через remoting), также могут предоставляться как веб-сервисы. JPA (Java Persistence API) - лишь часть спецификации EJB.

    > "2. Tomcat."

    Tomcat не является сервером приложений, это контейнер сервлетов. Т.е. EJB он не умеет.

    ОтветитьУдалить
  2. По поводу того что Tomcat не AppServer я согласен. :-) Спасибо.

    Но вот определение EJB-контейнера я взял с вики Отсюда.

    Оно не верно? Надо править вики.

    ОтветитьУдалить
  3. Здесь подробнее и правильней - http://ru.wikipedia.org/wiki/EJB - и указаны все типы EJB.

    Кстати, вот вы в своём проекте использовали web-сервисы и имели проблемы с XML-сериализацией. А можно было, например, дёргать сессионные EJB через remoting, тогда при передаче/возврате значений можно использовать любые стандартно сериализуемые типы. А если ту же EJB нужно дёрнуть как веб-сервис (например из дотнета) то можно сделать ей интерфейс для предоставления в виде веб-сервиса. Ну вопщем как-то так)).

    ОтветитьУдалить
  4. Спасибо за ссылку. :-)

    В итоге мы кстати не использовали AppServer, а сделали свой небольшой, который нам очень просто позволил опубликовать веб сервисы Jax-WS. Сложностей замечено не было. В плане сериализации мы стали использовать стандартную байтовую сериализацию, т.е. мы обернули прокси и вебсервис еще небольшим классом отвечающим за сер/десер.

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

    Получается что наш пул задач должен быть статичным на уровне всего АппСервера. Мы не смогли прицепить такой объект к готовым реализациям аппсерверов, но подобное очень просто сделать используя свой аппсервер (ну если это консольное приложение хостящее веб сервисы можно так назвать).

    Проект у нас движется, в начале-середине декабря заканчивается первая итерация, сделано с одной стороны много, с другой мало, ну как всегда в принципе :-), так что после итерации станет чуть спокойнее и я расскажу как у нас тут все получилось. :-)

    ОтветитьУдалить
  5. Да, по поводу EJB. Сейчас мне начинает казаться что мы все таки пошли чуть чуть не по тому пути.

    Но основные наши доводы за не использование EJB. Во первых, как нам показалось, удобно использовать весь набор EJB, начиная в первую очередь с EntityBeans, но мы решили отказаться от ORM, из за очень сложной реляционной модели. Далее мы отказались от использования SessionBean, потому что тут нам достаточно веб-сервисов, которые по сути являются тем же самым, но нам, как дотнетчикам, более понятны.

    Вот так вот мы и пришли к тому что есть сейчас. :-)

    ОтветитьУдалить
  6. Хотя может быть я не до конца еще разобрался что же такое SessionBean.

    Я понимаю что это удаленный объект, уникальный для каждого клиента, создается постоянно при обращении (если не используется stateful).

    Стандартная работа с SessionBean через Remoting, со всеми вытекающими плюсами и минусами.

    Верно?

    ОтветитьУдалить
  7. Хочу немного раскрыть "Во первых, как нам показалось, удобно использовать весь набор EJB, начиная в первую очередь с EntityBeans, но мы решили отказаться от ORM, из за очень сложной реляционной модели."

    Дело все в том что мы используем архитектуру Table Modules (по Фаулеру). Использование EntityBeans сразу заставляет использовать Domain Model (и это за собой тянет ORM, потому что такая связка максимально дает бонусы от DomainModel на EntityBean'ах), что нам не очень подходит.

    ОтветитьУдалить
  8. «Я понимаю что это удаленный объект, уникальный для каждого клиента, создается постоянно при обращении (если не используется stateful).

    Стандартная работа с SessionBean через Remoting, со всеми вытекающими плюсами и минусами.

    Верно?
    »

    Примерно так, Stateless Session соответствует дотнетовскому SingleCall. Ну это примерно, так как аналога EJB в майкрософтовских технологиях нет.

    И работа через ремотинг, да.

    Простейшее введение - http://blog.eros2.info/2009/04/ejb-3.html - я собирался писать больше, но обленился.

    Чуть глубже - http://wiki.linuxformat.ru/index.php/LXF99:Java_EE

    Но ORM с EJB использовать совершенно не обязательно, тут уже кому как больше нравится.

    ОтветитьУдалить
  9. "Но ORM с EJB использовать совершенно не обязательно, тут уже кому как больше нравится."

    Нет нет, я не про EJB вообще, а про EntityBean (но не SessionBean). Разве EntityBeanы это не DomainModel в чистом виде? А DomainModel без ORM не сможет показать себя во всей красе.

    ОтветитьУдалить