Comments 24
Маленький шажок для IBM и огромный скачек для всего кровавого энторпрайса. Тысячи несчастных, вынужденных разрабатывать для WAS вздохнули с облегчением.
Правильней, конечно, было бы выкинуть WAS на помойку и не рекомендовать его использовать. Но пока мы вынуждены мириться с этим злом, потому что различные банки и гос организации, вопреки всякой логике, продолжают его покупать. Так что это реально полезно может оказаться, если будет совместимость на уровне багов. Вот бы ещё в гос организациях и банках на новые версии побыстрее переходили.
Правильней, конечно, было бы выкинуть WAS на помойку и не рекомендовать его использовать. Но пока мы вынуждены мириться с этим злом, потому что различные банки и гос организации, вопреки всякой логике, продолжают его покупать. Так что это реально полезно может оказаться, если будет совместимость на уровне багов. Вот бы ещё в гос организациях и банках на новые версии побыстрее переходили.
Если не секрет, какая версия WAS и на какой платформе используется?
Мне любопытно, какие есть нарекания именно к продукту IBM WebSphere Application Server, исключая претензии к платформе JEE?
Да, он не идеален, но и не «ужас-ужас».
Чем разработка для WAS кардинально отличается от разработки под другие JEE сервера?
Мне любопытно, какие есть нарекания именно к продукту IBM WebSphere Application Server, исключая претензии к платформе JEE?
Да, он не идеален, но и не «ужас-ужас».
Чем разработка для WAS кардинально отличается от разработки под другие JEE сервера?
Я работал и работаю с разными версиями от 6.1 до 8.5.5. И это ужас-ужас. Я так же работал в разное время с JBoss, Glassfish, не говоря уже о Tomcat и Jetty. Ответственно могу заявить, что WAS — худший Application Server с которым я работал.
1. Основная проблема — это, конечно же, общая тормознутость. Тормозит решительно все. Даже раскрытие пункта меню в консоли администрирования тормозит. Т.е. нет, если тормозит мое приложение, то можно подумать что я — дурак. Но когда тормозит приложение написанное в IBM, возникает ощущение, что дурак кто-то другой.
2. Непомерное потребление ресурсов. Даже говорить об этом не хочется. Одни слезы. В итоге, на рабочих компах сфера стоит только у самых отважных разработчиков.
3. Конфигурация. Это просто ужас. Конфигурация раскидана по сложной иерархии каталогов. Запутана и непонятна. Название полей в консоли администрирования может не совпадать с названиями в файлах конфигурации. Т.е. конфигурировать WAS можно только из тормознутой консоли администрирования или при помощи скриптов, которые тоже отрабатывают не быстро. И всё бы было ничего, но она ломается! Приходит в несогласованное состояние. И вот тогда остается только копаться в этих XML-ках, т.к. никакая консоль и никакие скрипты не исправят ситуацию.
4. Тонны левых библиотек, не относящихся к JavaEE. Зачем? Зачем мне это? Если мне что-то понадобится, я просто положу это в EAR.
1. Основная проблема — это, конечно же, общая тормознутость. Тормозит решительно все. Даже раскрытие пункта меню в консоли администрирования тормозит. Т.е. нет, если тормозит мое приложение, то можно подумать что я — дурак. Но когда тормозит приложение написанное в IBM, возникает ощущение, что дурак кто-то другой.
2. Непомерное потребление ресурсов. Даже говорить об этом не хочется. Одни слезы. В итоге, на рабочих компах сфера стоит только у самых отважных разработчиков.
3. Конфигурация. Это просто ужас. Конфигурация раскидана по сложной иерархии каталогов. Запутана и непонятна. Название полей в консоли администрирования может не совпадать с названиями в файлах конфигурации. Т.е. конфигурировать WAS можно только из тормознутой консоли администрирования или при помощи скриптов, которые тоже отрабатывают не быстро. И всё бы было ничего, но она ломается! Приходит в несогласованное состояние. И вот тогда остается только копаться в этих XML-ках, т.к. никакая консоль и никакие скрипты не исправят ситуацию.
4. Тонны левых библиотек, не относящихся к JavaEE. Зачем? Зачем мне это? Если мне что-то понадобится, я просто положу это в EAR.
1 и 2.
Просто привожу то, что вижу на своей конфигурации.
WAS 8.5.5 (Standalone) в режиме «разработчика».
Платформа: Intel Core i5 (3.2 GHz), Windows 7 x64, HDD. RAM:12GB ( 3-4 виртуалки постоянно).
Время запуска: порядка 20 секунд. (С момента появления первой записи startServer.log до сообщения «Server <имя> open for e-business»)
Потребление ОЗУ: 160-200 МБ.
Запускается обычно раз в день, в начале дня.
Страницы консоли могут тормозить при первом обращении, т.к. происходит компиляция JSP-страниц и загрузка связанных ресурсов.
При дальнейшей работе консоль весьма «отзывчива». ИМХО, конечно же.
3. Согласен.
WAS не предназначен для конфигурирования вручную. Или скрипты, или консоль.
Плюс нужно не забывать делать резервирование конфигурации через backupConfig. Тогда в случае проблемы с конфигами можно поднять рабочую из резерва за несколько минут.
На 8.5+ пока случаев рассинхронизации конфигурации не встречал, возможно «пока».
Часто ли меняется конфигурация сервера и ресурсов сервера, что это настолько проблемное место?
4. Ну не «тонны», но много. Согласен.
И это уже «политика партии». Тут есть и плюсы и минусы.
Идея, что на одном сервере/кластере должны крутиться десятки приложений.
В этом случае затратно держать для каждого приложения копии библиотек внутри ear.
Поэтому, многие библиотеки есть в составе сервера. Плюс можно делать собственные Shared-библиотеки.
Т.е. концепция — «тяжелый сервер», который постоянно работает и «легкие приложения», которые в этом случае проще/быстрее можно обновлять.
Просто привожу то, что вижу на своей конфигурации.
WAS 8.5.5 (Standalone) в режиме «разработчика».
Платформа: Intel Core i5 (3.2 GHz), Windows 7 x64, HDD. RAM:12GB ( 3-4 виртуалки постоянно).
Время запуска: порядка 20 секунд. (С момента появления первой записи startServer.log до сообщения «Server <имя> open for e-business»)
Потребление ОЗУ: 160-200 МБ.
Запускается обычно раз в день, в начале дня.
Страницы консоли могут тормозить при первом обращении, т.к. происходит компиляция JSP-страниц и загрузка связанных ресурсов.
При дальнейшей работе консоль весьма «отзывчива». ИМХО, конечно же.
3. Согласен.
WAS не предназначен для конфигурирования вручную. Или скрипты, или консоль.
Плюс нужно не забывать делать резервирование конфигурации через backupConfig. Тогда в случае проблемы с конфигами можно поднять рабочую из резерва за несколько минут.
На 8.5+ пока случаев рассинхронизации конфигурации не встречал, возможно «пока».
Часто ли меняется конфигурация сервера и ресурсов сервера, что это настолько проблемное место?
4. Ну не «тонны», но много. Согласен.
И это уже «политика партии». Тут есть и плюсы и минусы.
Идея, что на одном сервере/кластере должны крутиться десятки приложений.
В этом случае затратно держать для каждого приложения копии библиотек внутри ear.
Поэтому, многие библиотеки есть в составе сервера. Плюс можно делать собственные Shared-библиотеки.
Т.е. концепция — «тяжелый сервер», который постоянно работает и «легкие приложения», которые в этом случае проще/быстрее можно обновлять.
Хотя бы тем, что это самый монструозный Application Server долго стартующий и пожирающий просто для своих нужд минимум с гиг памяти. Это монструозность мешает как раз в процессе разработки, замедляя ее — приходится по разному ухищряться чтобы этого не происходило. С точки зрения его функционала — не думаю, что кто-то будет выставлять какие-то особые большие претензии.
Насколько часто и по каким причинам нужно перезапускать сервер приложений в процессе разработки самих приложений?
Далеко не каждое изменение конфигурации сервера требует его перезапуска.
А если меняется само приложение — то обычно, максимум это нужно выполнить Uninstall/Install.
Подчеркиваю «обычно», поэтому и любопытны случаи, требующие частого перезапуска сервера приложений.
Возможно, я просто не сталкиваюсь с такими ситуациями.
Далеко не каждое изменение конфигурации сервера требует его перезапуска.
А если меняется само приложение — то обычно, максимум это нужно выполнить Uninstall/Install.
Подчеркиваю «обычно», поэтому и любопытны случаи, требующие частого перезапуска сервера приложений.
Возможно, я просто не сталкиваюсь с такими ситуациями.
> Подчеркиваю «обычно», поэтому и любопытны случаи, требующие частого перезапуска сервера приложений.
Да, это действительно не постоянно требуется, но в те моменты когда это приходится делать (пересоздание datasource, изменения в скриптах развертывания приложения в кластере и т.п.) — дико раздражает. Особенно когда вспоминаешь, что тот же Glassfish стартует практически мгновенно. Жить с этим можно, но без этого жить значительно лучше ;)
Да, это действительно не постоянно требуется, но в те моменты когда это приходится делать (пересоздание datasource, изменения в скриптах развертывания приложения в кластере и т.п.) — дико раздражает. Особенно когда вспоминаешь, что тот же Glassfish стартует практически мгновенно. Жить с этим можно, но без этого жить значительно лучше ;)
Все плохо. От административной консоли, конфигурации, мониторинга, до средств и методологии разработки и тестирования. Любое неосторожное (да и осторожное тоже) действие может положить весь профайл. Я уж не говорю про тормознутость и прожорливость этого всего, а до последних версий еще и багнутость. Еще хуже, когда приходится работать с продуктами IBM, которые построены на WAS, например Websphere Process Server, Portal, etc. Разработка и тестирование превращается в сущий ад. Программисты стонут: «ради бога, давайте мы на чем-нибудь другом напишем». И если клиент особо упертый, то сам же потом и страдает. Вот Oracle правильно сделал: не смог поднять свой JEE профайл — взял и купил с потрохами BEA. И обзавелся удобоваримым сервером для своих решений. Redhat тоже пошла на встречу разработчикам — шестерку переписали практически с нуля, так, что стартует за три секунды, а Arquillian облегчил разработку и тестирование. А что есть у WAS? Такое впечатление, что весь сервер писали инопланетяне — там нет ни одного человеческого решения.
«Все плохо» — это слишком общее.
Который раз слышу про «долгий старт». Насколько он долгий?
WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято. Т.е. время загрузки в пределах до 5 минут не является принципиальным моментом. Типичное время запуска порядка 1-2 минут, в зависимости от количества приложений.
Если нужна 100% доступность — нужно разворачивать кластер (Network Deployment), в нем перезапуск любого из узлов является прозрачным для конечных пользователей, за счет избыточности узлов.
«Прожорливость» была актуальна для ветки 6.x, в ветке 7.x и 8.x много чего делалось с точки зрения оптимизации. Более детальный разговор требует фактов и цифр.
Насчет WebSphere Portal — 100% согласен, продукт неудачный (ИМХО). С Process Server не сталкивался.
Для разработки под WAS есть:
— Rational Application Developer (платный продукт)
— Eclipse + «IBM WebSphere Application Server Developer Tools for Eclipse». (бесплатный продукт).
В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости, ведения журналов и т.п. вещей. Если все это «добро» в проекте не используется, то вопрос к правильности выбора платформы для проекта.
Который раз слышу про «долгий старт». Насколько он долгий?
WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято. Т.е. время загрузки в пределах до 5 минут не является принципиальным моментом. Типичное время запуска порядка 1-2 минут, в зависимости от количества приложений.
Если нужна 100% доступность — нужно разворачивать кластер (Network Deployment), в нем перезапуск любого из узлов является прозрачным для конечных пользователей, за счет избыточности узлов.
«Прожорливость» была актуальна для ветки 6.x, в ветке 7.x и 8.x много чего делалось с точки зрения оптимизации. Более детальный разговор требует фактов и цифр.
Насчет WebSphere Portal — 100% согласен, продукт неудачный (ИМХО). С Process Server не сталкивался.
Для разработки под WAS есть:
— Rational Application Developer (платный продукт)
— Eclipse + «IBM WebSphere Application Server Developer Tools for Eclipse». (бесплатный продукт).
В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости, ведения журналов и т.п. вещей. Если все это «добро» в проекте не используется, то вопрос к правильности выбора платформы для проекта.
> WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято.
А как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же… Так что спросите у любого как они выкручиваются, и вам ответят, что веб они строчат на легком Tomcat-е и уже потом в продакшн деплоят на WAS. Когда же логика сложная, и такая фишка не проходит, то этот тяжелый серверный продукт пускают локально на девелоперской машине, чтобы можно было более-менее дебагить нормально. Так что с этой точки зрения облегченный профайл — правильный шаг в этом направлении.
> Если нужна 100% доступность — нужно разворачивать кластер
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
> В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости,
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Так что IBM нужно менять стратегию и ориентироваться на живых людей. То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2. Сорри за субъективизм.
А как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же… Так что спросите у любого как они выкручиваются, и вам ответят, что веб они строчат на легком Tomcat-е и уже потом в продакшн деплоят на WAS. Когда же логика сложная, и такая фишка не проходит, то этот тяжелый серверный продукт пускают локально на девелоперской машине, чтобы можно было более-менее дебагить нормально. Так что с этой точки зрения облегченный профайл — правильный шаг в этом направлении.
> Если нужна 100% доступность — нужно разворачивать кластер
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
> В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости,
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Так что IBM нужно менять стратегию и ориентироваться на живых людей. То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2. Сорри за субъективизм.
как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же…
Разрабатывать для WAS очень желательно и весьма удобно в Rational Application Developer.
В нем есть встроенные средства для публикации изменений на сервер приложений (локальный или удаленный) через интерфейсы RMI и SOAP. При этом публикация может происходить автоматически (после сохранения изменений) или вручную (по нажатию кнопки Publish). При этом, в случае удаленного сервера генерируется дельта-файл, содержащий изменения, а в случае локального — может просто посылаться сигнал перечитать конфигурацию. Задержки при этом — минимальные.
Работая в RAD с локальным сервером приложений и меняя свое приложение я моментально могу посмотреть результат в браузере, не нажимая ни одной кнопки, кроме «Сохранить». Да, иногда бывают случаи (например при изменении binding), когда сервер не подхватывает изменения, в таком случае из среды разработки требуется выполнить установку/удаление приложения.
Относительно недавно аналогичный функционал стал доступен для среды Eclipse, о чем я уже писал выше.
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
При разворачивании новых версий приложения я знаю следующую практику:
1. Новая версия разворачивается с другим именем, содержащим номер версии в остановленном состоянии.
2. Останавливается существующая версия приложения.
3. Запускается новая версия приложения.
4. Если с новой версией что-то «не так», новая версия останавливается, предыдущая — запускается.
Все работает, все довольны. Простой — минимален.
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Как говорит IBM — It depends…
То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2
Из этой группы я бы однозначно исключил Websphere Message Broker и Websphere MQ.
Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
PS: К сожалению не смогу отвечать на комментарии до вечера (20:00 МСК), тк буду далеко от интернета.
При разворачивании новых версий приложения я знаю следующую практику:
1. Новая версия разворачивается с другим именем, содержащим номер версии в остановленном состоянии.
2. Останавливается существующая версия приложения.
3. Запускается новая версия приложения.
4. Если с новой версией что-то «не так», новая версия останавливается, предыдущая — запускается.
Все работает, все довольны. Простой — минимален.
Еще хотелось бы добавить, что в версии WAS 8.5 появилась такой функционал как Intelligent Management. Одна из возможностей которого это Application edition management. Application edition management — позволяет запускать несколько версий одного и того же приложения.
> Разрабатывать для WAS очень желательно и весьма удобно в Rational Application Developer.
Ну разве что недавно допилили. До этого приходилось постоянно делать publish, который передеплоил все приложение. Remote debug безбожно тормозил, а иногда и подвисал. Сервер после нескольких дебагов работал все медленнее.
> При разворачивании новых версий приложения я знаю следующую практику
Да, нам тоже IBM советовали это. Но таким образом теряются сессии пользователей. Если я поменял одну страничку или пару классов, мне не хочется всех напрягать перелогиниваться.
> Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
Если под качеством IBM подразумевает исключительно стабильное поведение в продакшне, то может быть. Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Так что как я уже сказал выше, есть твердое впечатление от продуктов IBM, что они сделаны не для живых людей.
Ну разве что недавно допилили. До этого приходилось постоянно делать publish, который передеплоил все приложение. Remote debug безбожно тормозил, а иногда и подвисал. Сервер после нескольких дебагов работал все медленнее.
> При разворачивании новых версий приложения я знаю следующую практику
Да, нам тоже IBM советовали это. Но таким образом теряются сессии пользователей. Если я поменял одну страничку или пару классов, мне не хочется всех напрягать перелогиниваться.
> Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
Если под качеством IBM подразумевает исключительно стабильное поведение в продакшне, то может быть. Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Так что как я уже сказал выше, есть твердое впечатление от продуктов IBM, что они сделаны не для живых людей.
Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS.
А вы точно про IBM WebSphere MQ? Если да то какой версии?
Надежный, кроссплатформенный продукт для быстрой и гарантированной доставки приложений.
При этом, с единым интерфейсом программирования для всех платформ.
При этом с библиотеками для очень многих языков программирования.
Для Java есть или базовые классы MQ, или JMS.
JMS-интерфейс там вполне стандартен, в актуальных версиях является стандартным JCA-адаптером. Те нормально (без шаманств) встраивается в сервера, поддерживающие спецификацию JCA.
В версии 6.x были проблемы с производительностью определенных JMS-операций. Так в версии 7.x перенесли выполнение этих операций с JMS-библиотек на серверную часть MQ. Т.е. современный WebSphere MQ весьма неплохо оптимизирован для работы с JMS-интерфейсом.
Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
И опять это явно не про тот WebSphere MQ, с которым я знаком.
GUI инструмент, который называется WebSphere MQ Explorer, идет в комплекте уж точно с версии 5.3, про более ранние — не помню. Причем достаточно давно его можно скачать отдельно от серверной и клиентской части. Он бесплатен и весьма функционален. Есть доп. плагины для еще большего расширения функционала. И им же можно генерировать JNDI-описания для Java SE, если вдруг возникает такая необходимость.
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Суть WebSphere Message Broker (который ныне IBM Integration Bus) в том, чтобы не писать в явном виде программный код. И при этом выполнять задачу интеграции приложений по разным протоколам/форматам/маршрутам.
Есть знания Java и XSL — отлично, там есть и Java Compute Node и XML Transformation Node.
Можно работать с WebSphere Message Broker и не знать что такое ESQL.
Да и если понадобится ESQL, он не особо отличается от PL/SQL или SQL/PL, язык простой, зная SQL и прочитав хотя бы пару уроков можно быстро вникнуть в суть алгоритма. XSL-шаблоны освоить по-моему сильно сложнее.
Много ли продуктов дают возможность принимать информацию практически из любого источника (MQ, JMS, FTP, HTTP, WebService, SAP Adapter, Database, Mail и т.д. и т.п.), парсить содержимое, перенаправлять/преобразовывать/дополнять и т.д. и т.п. и, отдавать на выходе в не меньшем количестве вариантов? При этом, зачастую, можно вообще не написать ни строчки кода. ИМХО продукт очень и очень хорошо решает тот круг задач, для которых был создан.
> GUI инструмент, который называется WebSphere MQ Explorer
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно. У меня не получилось, потому что все сделано как всегда через одно место, в стиле IBM. Вместо простой формочки, которую ожидает любой нормальный пользователь с полями: QM name, host/port, user, password, там только два поля: QM name и connection name. После получаса искания в документации оказалось, что connection name нужно писать в формате host(port), а не как привыкло 99% людей в мире: host:port. В итоге все-равно ничего не заработало, т.к. на сервере был выключен remote administration. Не понимаю, нахрен что-то там еще включать, чтобы чисто посмотреть очереди и их содержимое, если ни WMQTool, ни любой клиент этого не требует. Ну да ладно. Ввели на сервере магическую команду включения remote administration. И теперь благополучно выскакивает ошибка аутентификации. Даже при том, что аутентификация в QM выключена вообще. Посмотрев логи MQ (а это тоже надо уметь делать, ибо это вам не syslog) становится понятно, что MQ Explorer пытается залогиниться с локальным (windows!) пользователем!!! И что такой же пользователь должен существовать на машине с QM (это юникс) и быть членом группы mqm даже при выключенной аутентификации. В MQ Explorer отсутствует напрочь человеческая возможность ввести user credentials. Ладно, сознаем виндового пользователя «Administrator» на юникс машине и добавляем в группу mqm. Как несложно догадаться, опять ничего не заработало. И порывшись в интернетах находим официальное объяснение от IBm, что Websphere MQ не любит имена пользователей больше 11 символов (Administrator=13). Об этом официально написано.
И вот подобная хрень практически с любым продуктом IBM. В итоге просто сдают нервы.
> Много ли продуктов дают возможность принимать информацию практически из любого источника
Да полно Вам!!! Полно opensource и коммерческих решений как полномасштабные ESB: Mule, Fuse/Apache ServiceMix, OpenESB, Oracle ESB; так и отдельные message-серверы: ActiveMQ, HornetQ, SonicMQ… Большинство продуктов в минимальной конфигурации вообще представляют собой lightweight библиотеку. Active MQ+Apache Camel решает те же задачи, что и Websphere MQ+Broker. Поэтому думать, что IBM здесь делает что-то уникальное, вкорне неверно. Просто в один момент заняли рынок MoM как Oracle в свое время занял рынок баз данных.
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно. У меня не получилось, потому что все сделано как всегда через одно место, в стиле IBM. Вместо простой формочки, которую ожидает любой нормальный пользователь с полями: QM name, host/port, user, password, там только два поля: QM name и connection name. После получаса искания в документации оказалось, что connection name нужно писать в формате host(port), а не как привыкло 99% людей в мире: host:port. В итоге все-равно ничего не заработало, т.к. на сервере был выключен remote administration. Не понимаю, нахрен что-то там еще включать, чтобы чисто посмотреть очереди и их содержимое, если ни WMQTool, ни любой клиент этого не требует. Ну да ладно. Ввели на сервере магическую команду включения remote administration. И теперь благополучно выскакивает ошибка аутентификации. Даже при том, что аутентификация в QM выключена вообще. Посмотрев логи MQ (а это тоже надо уметь делать, ибо это вам не syslog) становится понятно, что MQ Explorer пытается залогиниться с локальным (windows!) пользователем!!! И что такой же пользователь должен существовать на машине с QM (это юникс) и быть членом группы mqm даже при выключенной аутентификации. В MQ Explorer отсутствует напрочь человеческая возможность ввести user credentials. Ладно, сознаем виндового пользователя «Administrator» на юникс машине и добавляем в группу mqm. Как несложно догадаться, опять ничего не заработало. И порывшись в интернетах находим официальное объяснение от IBm, что Websphere MQ не любит имена пользователей больше 11 символов (Administrator=13). Об этом официально написано.
И вот подобная хрень практически с любым продуктом IBM. В итоге просто сдают нервы.
> Много ли продуктов дают возможность принимать информацию практически из любого источника
Да полно Вам!!! Полно opensource и коммерческих решений как полномасштабные ESB: Mule, Fuse/Apache ServiceMix, OpenESB, Oracle ESB; так и отдельные message-серверы: ActiveMQ, HornetQ, SonicMQ… Большинство продуктов в минимальной конфигурации вообще представляют собой lightweight библиотеку. Active MQ+Apache Camel решает те же задачи, что и Websphere MQ+Broker. Поэтому думать, что IBM здесь делает что-то уникальное, вкорне неверно. Просто в один момент заняли рынок MoM как Oracle в свое время занял рынок баз данных.
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно.
Пользуюсь, практически каждый день.
Работаю удаленно с менеджерами на Windows, Linux, z/OS.
Действия для подключения к удаленному менеджеру (MQ Explorer V 7.5, который умеет подключатся к менеджерам версии 6.0 и выше):
1. Запустить MQ Explorer.
2. Щелкнуть правой клавишей мышки на разделе Queue Managers
3. Выбрать пункт «Add Remote Queue Manager»
4. Ввести имя менеджера, к которому нужно подключиться. Поле: «Queue Manager Name»
5. Выбрать опцию «Connect Directly».
6. Нажать Next.
7. Ввести параметры соединения:
«Host Name or IP Address» — DNS-имя или IP-адрес сервера
«Port number» — номер порта TCP/IP
«Server-connection channel» — имя канала, через который будет выполняться подключение
8. Нажать Next.
9. Нажать Next.
10. Поставить галку «Enable user identification»
После этого ввести имя пользователя и пароль, которые существуют на сервере MQ.
Поле «Userid» и кнопка «Enter password»
11. Нажать Finish.
Собственно на этом все, можно пользоваться.
Это правда «нереально сложно»?
Похоже, что ваше знакомство состоялось с весьма старыми версиями этих продуктов и как то «не сложилось».
Современные версии продуктов IBM WebSphere MQ, IBM WebSphere Message Broker, IBM WebSphere Application Server и инструментов для работы с ними достаточно приятны в «общении», ИМХО конечно же.
Да, там не все и не всегда «интуитивно понятно». Но, есть документация, которая доступна публично, и легко гуглится, есть форумы, есть тех.поддержка, которая отвечает на самые разные вопросы.
Так было в версии 5.3, с которой мы начинали. В 6.0 MQ Explorer переписали под Eclipse RCP, и наконец, добавили параметры коннекта, однако забыли про аутентификацию. Видимо только в 7.0 (по прошествии ) гениальная инженерная мысль сэволюционировала до завершенного диалога со всеми необходимыми параметрами — не знаю. Последнее, чем я пользовался это 6.0. И тем не менее, уверен, что до сих пор отсутствует нормальная возможность просмотреть содержимое сообщения (payload), ввиде человеческого текста (или XML), а не шестнадцатеричного дампа, который по крайней мере бы можно было скопипастить. В 6.0 также напрочь отсутствует возможность сохранить сообщение на диск. А окно Put Test Message имеет строку ввода Message Data, куда можно ввести полтора слова, без header-ов.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
И тем не менее, уверен, что до сих пор отсутствует нормальная возможность просмотреть содержимое сообщения (payload), ввиде человеческого текста (или XML), а не шестнадцатеричного дампа, который по крайней мере бы можно было скопипастить
Ну и зря вы так уверены в этом. В MQ Explorer это есть. И заголовки можно посмотреть, и сообщение отображается и текстом и HEX-дампом.
В 6.0 также напрочь отсутствует возможность сохранить сообщение на диск.
Для загрузки/выгрузки сообщений можно и нужно пользоваться утилитой MO03, которая доступна на страничке WebSphere MQ — SupportPacs by Product аж с 2005 года!
А окно Put Test Message имеет строку ввода Message Data, куда можно ввести полтора слова, без header-ов.
Оно четко выполняет свою функцию — отправить тестовое сообщение. Если нужно специфичное форматирование и заполнение спец. заголовков — есть IH03(RFHUtil). Он, кстати, тоже позволяет сохранять сообщения на диск и читать их с диска.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
Т.е. у Вас все таки есть какие-то претензии к основному функционалу (доставка сообщений), стабильности, производительности и отказоустойчивости этого продукта (IBM WebSphere MQ)? Если есть, озвучьте пожалуйста. Я пока не увидел ни одной. Он теряет сообщения? Не справляется с нагрузкой? Не реализует заявленные свойства? Есть проблемы при работе через какие-то API?
В чем проявляется его «сырость», кроме того факта что лично вам с ним «неудобно»? И если Вам при работе с этим продуктом было неудобно и непонятно, Вы (или Ваша компания) открыли отчет о проблеме (PMR) в IBM? Попросили поддержки и помощи в их решении?
Озвученное выше выглядит так, как будто Вы продукт «пощупали» мимоходом, даже не прочитав толком документацию, не познакомившись с архитектурой и особенностями. И, кроме того, даете оценку продукта в общем, не указывая версию/платформу, основываясь на мнении N-лет давности. А все меняется, что-то быстрее, что-то медленнее, но — меняется.
«Cовместимость на уровне багов» — нет, нету. Более того, не все фичи WAS работают в Liberty Profile, что иногда заставляют сильно ломать голову и, по-сути, делают Liberty Profile лишней головной болью.
Liberty Profile — потенциально очень интересное решение. Максимально облегченный профиль, который легко «заточить» под свое приложение и поставлять весь комплект как единое целое.
Наиболее подходящ (ИМХО) для разработки новых приложений. При этом, то, что сделано для LP, с высокой вероятностью (говорю про вероятность, т.к. официальных гарантий от IBM не встречал) будет работать и на полном профиле того же уровня.
Наиболее подходящ (ИМХО) для разработки новых приложений. При этом, то, что сделано для LP, с высокой вероятностью (говорю про вероятность, т.к. официальных гарантий от IBM не встречал) будет работать и на полном профиле того же уровня.
Помню был у меня случай с этим говномостром.
Писал очень простое приложение для заказчика. Обычный war. Разрабатывали его под tomcat. Когда заказчик всю работу принял, он ненароком попросил установить приложение ему в прод, где стояла эта шляпа. Два дня я мучался, чтобы приложение заработало. То одно, то второе, то третье.
Сплошные конфликты библиотек, которые не решались тем, что в админке поставить галочки, которые определяют приоритет библиотек.
Получив опыт работы с данной шляпой, я себе сказал, что никогда в жизни более не буду работать с этим монстром…
Писал очень простое приложение для заказчика. Обычный war. Разрабатывали его под tomcat. Когда заказчик всю работу принял, он ненароком попросил установить приложение ему в прод, где стояла эта шляпа. Два дня я мучался, чтобы приложение заработало. То одно, то второе, то третье.
Сплошные конфликты библиотек, которые не решались тем, что в админке поставить галочки, которые определяют приоритет библиотек.
Получив опыт работы с данной шляпой, я себе сказал, что никогда в жизни более не буду работать с этим монстром…
На правах рекомендации на будущее, мало ли еще столкнетесь со сферой ;)
Я и согласен с тем, что сфера — монстр, но все конфликты на уровне приложения в большинстве случаев решаются установкой для класслоадера приложения более высокого приоритета, чем для класслоадера сферы. В этом случае приложение начинает в первую очередь использовать свои библиотеки, а не сферовские. Данный подход покрывает не 100% случаев, но 99% точно.
Я и согласен с тем, что сфера — монстр, но все конфликты на уровне приложения в большинстве случаев решаются установкой для класслоадера приложения более высокого приоритета, чем для класслоадера сферы. В этом случае приложение начинает в первую очередь использовать свои библиотеки, а не сферовские. Данный подход покрывает не 100% случаев, но 99% точно.
Зачем называть продукт монстром, если в реальности была ваша ошибка в планировании требований для приложения.
На самом деле, самая большая проблема продуктов IBM это отсутствие информации в интернете. Любая проблема не описанная в документации (которая имхо очень средняя) — ищите решение сами. Любое расширение непредусмотренное IBMом — нервы, маты и очень долгий дебаг. А сам WAS достаточно неплох для интерпрайза.
Sign up to leave a comment.
WebSphere Application Server Liberty Profile