Анонсирован (http://pilhuhn.blogspot.com/2011/05/rhq-4-released.html) релиз RHQ 4.0 (http://rhq-project.org/), открытой системы централизованного управления, конфигурирования, инвентаризации и мониторинга за работой программного обеспечения на машинах в сети предприятия. Код (http://sourceforge.net/projects/rhq/files/rhq/rhq-4.0.0/) RHQ написан на языке Java и распространяемая в рамках лицензии GPL. Платформа построена по модульному принципу и позволяет организовать управление практически всеми аспектами работы операционной системы и пользовательских приложений. RHQ позволяет контролировать работу web-серверов Apache, контейнеров Apache Tomcat, сервера приложений JBoss, базы данных PostgreSQL и других популярных открытых проектов.
Ключевые новшества (http://rhq-project.org/display/RHQ/Release+Notes+4.0.0) RHQ 4.0:
- Новый web-интерфейс, базирующийся на SmartGWT (http://code.google.com/p/smartgwt/) и функционирующий с использованием технологии Ajax. Из отличий от прошлого we...URL: http://pilhuhn.blogspot.com/2011/05/rhq-4-released.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=30476
Есть аналоги не на Java?
Тысячи их.
Chef, cfengine, bcfg2, puppet и иже с ними.
Если нужен мониторинг того же уровня (ынтерпрайз) - Zenoss
Скажите, это просто мне не приходилось сталкиваться с этими Ынтерпрайз системами или у многих недоумение от шумихи этого странного муравейника? Много в последнее время новостей о всяких JBoss или вот таких вот системах, но сколько я не ковырялся по сайтам и документации этих систем, так и не понял, где их применять. Из описаний ничего непонятно. Вобще ничего. Возьмите этот RHQ. Отрывок из описания:
"управления, конфигурирования, инвентаризации и мониторинга за работой программного обеспечения на машинах в сети предприятия".
Это что? Теперь юзеры сами не управляют своими компами? Теперь один мага-админ единолично работает за всех и на всех компах?
Или это:
"контролировать работу web-серверов Apache"
Я всегда на всех серверах предпочитаю контролировать веб-сервер самостоятельно. И инструмент мой - консольный текстовый редактор. Так что же это тогда? Гуй для правки конфигов?
Или вот например отрывок из описания JBoss:
"market leading platform for innovative and scalable Java applications".
Напрашивается вполне законный вопрос: "И шо? Ну Scalable, ну Innovative, ну Java. А что он делает?!! Функциональная нагрузка в чём заключается?"
Большинство из этого в последнее время всплывающего айсберга написано на Java. Может совпадение а может и нет. Может я ничего не понимю в религии Java? Единственное что я понимаю из этого айсберга - это так называемые нереляционные СуБД, с ними всё понятно и вроде как перспективное направление, свою нишу точно найдёт.Не подумайте что я придорок какой-то, или тролль, просто уже хрен знает какая по счёту новость этого типа, а я всё никак не врубаюсь. Я довольно сложными вещами занимаюсь, пользуюсь несколькими языками программирования вполне успешно, проектирую высоконагруженные системы с нуля, патчи бывает отправляю если ошибки в свободном софте нахожу и могу исправить, в общем не сайтики какие-то пишу. А чувствую себя полным дауном когда когда читаю новости о подобных проектах. Вот всегда понимаю о чём речь, а если мелькает слово "Java" - сразу явно простые вещи написаны каким-то Ынтерпрайзно-религиозным языком.
P.S. Убеждать меня в правильности Ынтерпрайза и рассказывать что я ничего не понимаю в этом мире и "серьёзных" проектах в частности безполезно, не тратьтье время, я всё равно анархист, Муаммар Каддафи и Жак Фреско рулят и всё такое.
P.P.S. Также не стоит воспринимть это как критику стиля подачи новостей. Судя по тому что на сайтах этих систем такая же муть виноват в запудривании мозгов простого пролетариата разработчиков очевидно первоисточник.
ну чтобы понять - нужна необходимость в продукте ;)
берем продукты IBM: тиволи (всякие), вебсферу, CICS, Lotus Domino Notes...
Если их не используешь - понять сложно, для чего это нужно ;)
> берем продукты IBM: тиволи (всякие), вебсферу, CICS, Lotus Domino Notes......но гораздо лучше держаться от них подальше. Если вы хотите неповоротливый, глючный, тормозной и проблемный софт - спрашивайте что-нибудь энтерпрайзное. Тиволи, вебсферы и прочие домино - отличные примеры! Если они вам нужны - вы ПОПАЛИ!
Это с точки зрения практики использования. А с точки зрения практики внедрения получается ситуация очень похожая на байку которую я слышал ещё во времена Windows98. Байка заключалась в том что сайт microsoft.com корректно отображается только в IE - так как же несчастные пользователи UNIX сидящие на тогдашней замечательной Мозилле 1.3 смогут узнать о том что есть такая обалденная система Windows и захотеть её купить? Так и здесь ситуация интересная: если я не пользовался этими системами - я не знаю, зачем они нужны. А если бы пользовался - знал бы. Но если не знаю зачем нужны - не посоветую как специалист начальнику приобрести для предприятия такую. А сам начальник в 99,99% случаев будет далёк от этого всего. Ему нужно чтобы он заплатил бабло, а предприятие стало работать эффективнее. Ему это даже не нужно пока он не знает о том что есть такая возможность. Что это за система и какие у неё преимущества/недостатки ему наплевать. И он точно не знает зачем оно ему нужно пока я не обращу на неё его внимание. Поэтому вся эта система продажи и обслуживания держится на промывании мозгов специалистам а не начальником. Пообщавшись с несколькими сотрудниками майкрософта, причём не самыми последними людьми в компании я точно дал диагноз: "зомби". Однако это ещё не значит что все Java или .NET девелоперы зомби, но достаточно некоторого процента таких вот зомби-сотрудников ентерпрайз-предприятий чтобы система жила и дальше. А те кто приходит от имени внедряющей фирмы и внедряет - те как раз совсем не зомби, они просто бабло рубят, а куда деваться, система такая, деньги всем нужны и много их не бывает. Это конечно пока деньги в сегодняшнем ничем не подтверждённом виде существуют, а это будет ещё довольно долго, хотя и не вечно.
>"управления, конфигурирования, инвентаризации и мониторинга за работой программного обеспечения на машинах в сети предприятия".
>Это что? Теперь юзеры сами не управляют своими компами? Теперь один мага-админ единолично работает за всех и на всех компах?
>Или это:
>"контролировать работу web-серверов Apache"
>Я всегда на всех серверах предпочитаю контролировать веб-сервер самостоятельно. И инструмент мой - консольный текстовый редактор. Так что же это тогда? Гуй для правки конфигов?Вроде того. Вот представьте себе компанию покрупнее, у которой не один мега-сервер с апачем и другой с постгресом, а пользователей обслуживает один виндовый быдлоадмин, решающий их проблемы. А что-нибудь покрупнее - уже при сотне пользователей даже несколько админов начнут не справляться без инструментов контролировать, у кого какое железо (он же меняется, чинится, расширяется и т.д.), у кого какой софт, у кого какие настройки - кому разрешено какими прогами пользоваться, куда лазить и т.д. У всех ли нормально прописаны DHCP, прокся, и т.д. и т.п. Вначале можно использовать пачку самописных диагностических скриптиков и тесктовый файлик, но это начинает отнимать много времени, и хочется централизованный инструмент для учета и контроля. Это про пользователей.
Что касается серверов, вот у нас к примеру три стойки серверов - на которых бегает куча всего. Конечно, можно помнить про все апачи, про все постгресы, про все мускули, про все прочие по отдельности - и все вместе? А когда админов больше одного? А быстро проверить, что все на всех серверах работает? А искать проблемы железа? Опять же, тут спасает инструмент, в который занесено, что где есть и который позволяет быстро все проверить и внести необходимые изменения туда, куда нужно. Конечно, можно зайти на сервер и поправить конфиг апача. А если пока вы были в отпуске, второй админ поднял еще один апач на другом сервере, забыв сказать вам, и там тоже нужно изменить? Вот с такой системой вы про это не забудете - она сама выполнит изменение везде, где требуется и проконтролирует.
> Или вот например отрывок из описания JBoss:
> "market leading platform for innovative and scalable Java applications".
> Напрашивается вполне законный вопрос: "И шо? Ну Scalable, ну Innovative, ну Java. А что он делает?!! Функциональная нагрузка в чём заключается?"JBoss это application server, вам это определение знакомо, или тоже сразу относите к "маркетинговой ерунде"? Раз уж вы занаете про апач, вот вам пример - в апаче бегают cgi-скрипты, ну скажем через mod_perl или mod_php. Чтобы оптимальнее и лучше. Это означает некий интерфейс, который специфичен для апача; под, скажем, nginx'ом ваш скрипт не заработает. Тут скрипт может быть, скажем, частью вебсайта, а httpd для него - application server.
А для Jav'ы спецификации того, что вы можете делать из аналога этого "скрипта" намного больше. Благодаря спецификациям вроде JavaEE и EJB вы можете писать код, работающий через развесистые интерфейсы с различными технологиями, библиотеками, БД и т.д. При этом не напрямую вызывая это все, а "переносимым" способом, используя возможности, предоставляемые мощным application server'ом, который обеспечивает функционирование вашего приложения вместе с другими и обеспечивает им взаимодействие с тем, что для вашего продукта нужно. Примерно как apache httpd+mod_perl+скрипт дает больше возможностей, чем тупо запускаемый скрипт в отрыве от всего. Вот JBoss - это один из таких application server'ов. И запускать под ним можно не только вебсайты, но и другие сервисы - т.к. писать продукты, работающие через его стандартиризованные интерфейсы проще/удобнее/надежнее, чем напрямую дергать кучу библиотек из кода.
Я кажется понял область применения. Поправьте, если ошибаюсь. Возьмём для примера контору, в которой несколько программистов проектируют какой-нибудь проект/стартап/не_важно_как_назвать. Их несколько человек. С момента запуска проекта появляется одновременно больше денег и больше проблем. Решение - нанять больше программистов. Но в коде-то разбираются только несколько человек. А вот если с начала разработки взять какую-нибудь общую широкоизвестную идею проектирования системы, например, MVC, то другим разработчикам будет проще и быстрее разобраться, нужно лишь потратить немного времени и объяснить им где M, где C, а где V. Здесь та же идея только не для программистов а для сисадминов и в полностью готовом виде? И готовность этого вида заключается в реализованной системе классификации и учёта действий админа?P.S. За объяснение JBoss отдельное спасибо. Кажется, заодно приблизился к постиганию смысла слова Middleware.
> в апаче бегают cgi-скрипты, ну скажем через mod_perl или mod_phpТак всё-таки через cgi или через mod_perl/mod_php?
Stax>Раз уж вы занаете про апач, вот вам пример - в апаче бегают cgi-скрипты, ну скажем через mod_perl или mod_php.... зал взрывается аплодисментами! Проффи новой закваски! Made in Skolkovo :)
none_first парвильно вам пример приводит.
Посмотрите программные продукты Tivoli.Существует общепринятые обозначения таких систем.
Система инвентаризации и мониторинга обычно собирает информацию о всём аппаратном и программном обеспечении компьютеров в корпоративной сети. И это бывает очень актуально. Представьте, что у вас завод с 7-8 тыс. компов. Вам надо знать, можете ли вы внедрить определенное ПО, позволяющее упростить работу сотрудников завода. У ПО есть требования к железу и ОС. Получив собранные системой инвентаризации вы знаетее, сколько компов у вас проходит требования, а сколько нет. Что в них надо поправить, например добавить ОЗУ или переустановить Windows (98/ME -> XP).
Кроме того, если задаться такой целью, можно видеть, что пользователь поставил игрушку и дать по шапке. Или узнать что из одного из этих 7000 компов сперли планку оперативки и вовремя дать по шапке... и т.д. применений масса и потребность в таких системах достаточно высокая...Пример такой системы Tivoli Configuration Manager.
Системы мониторинга позволяют отслеживать состояние машин в сети в реальном времение (чаще всего это относится к серверам). Т.е. если у вас критически важный для работы подразделений компании сервер рапортует о том, что у него загрузка ЦП колеблется в определенные моменты около 100% это повод задуматься. Также можно мониторить загрузку корневых маршрутизаторов сети и прочее... Применяются такие системы реже.
И написанно оно чаще всего не на Java. На Java имеет смысл писать только Server Side. А вот агентов (приложения которые разворачиваются на конечных машинах, состояние которых мониторят) чаще всего пишут на C++. Потому как если на конечной машине 256 мб оперативы и она выполняет свои функции нормально (далеко не всегда нужны современные компы), то ставить java-приложение которое уест мегов 100 не очень правильно. Правда IBM попыталась использовать написанные на java агенты. По крайней мере в нашей стране не пошло.
И кстати зря вы по поводу Java, не только на Java пишут. Например посмотрите на microsoft system center configuration manager и вобще на линейку microsoft system center. На Java пишут чаще из-за того что Java по сути корпоративный стандарт для ServerSide (все дело в обилии готовых компонентов решающих типичные задачи, ярчайшим примером является Apache Camel, набор jar'ников с помощью которого можно решать интеграционные задачи без единой строчки кода. Насколько я знаю такого на других платформах просто нет).
Я понял, на мой вопрос "это просто мне не приходилось сталкиваться с этими Ынтерпрайз системами?" ответ утвердительный. А если в подробностях - честно говоря, не хватило фантазии на цифру в 7000 компов. Когда-то давно писал сайт для одного завода, заодно пообщался с местными разработчиками. Предприятие серьёзное, но там явно не было столько компов, основная проблема сводилась к бухгалтерии (между прочим, проблема очень и очень объёмная) - это мне и представлялось более-менее Ынтерпрайзом, а вот до масштаба трагедии в 7000 компов реально не додумался. Конечно, тут возникают новые задачи.
Кстати, я не являюсь яростным противником Явы. Может, я и за гнутый софт до мозга костей, но от всего что я запускал явовского ощущение очень приятное. Чаще всего это были небольшие программки, которые "просто работают" на любой ос/конфигурации/везде_где_есть_ява_а_это_много. И цель "просто работает" весьма и весьма достойная для метода "корпоративный стандарт".
А вот от MS ощущение не такое радужное. Работал как-то с сотрудником небезизвестной M$. Он поднимал сайт на Sharepoint. Громко сказано "поднимал", правда? Так вот это самое "поднимал" здесь нужно писать с включённым CapsLock, т.к. дело действительно являлось героическим подвигом. Для того чтобы под этим чудом поднять просто сайт на WordPress с парой-тройкой нестандартных наворотов от M$, сожралось ни много ни мало 4 гига оперативки. На сервере было 16 гигов, большая часть из которых уходила на виртуальные машины. Так вот, то ли лицензия, то ли ещё какие-то ограничения не позволяли поднять ещё один Wordpress на этом же Sharepoint. Решением было поднять два Sharepoint'а на сервере. Но во-первых извращение страшное, во вторых не хватило оперативки и от идеи пришлось отказаться.
Капитализм, мать его, культ потребления. Недавно вот мышь поменял девушке с PS/2 на USB так пришлось винду переставить чтоб заработало, т.к. винда навернулась а в бэкапе, сделанном PartImage'м из под Линуха не было установлено ни драйверов USB мыши (да, за пару недель до этого ещё и мышь накрылась), ни USB клавы. И каким же издевательством выглядело на экране сообщение "найдено новое оборудование" и кнопка "всё равно продолжить"! Это что получается? Поменял PS/2 на USB - купи новую винду? А хочешь новую винду - поставь больше оперативки? А хочешь больше оперативки - поменяй материнку? А хочешь новую материнку - купи новый блок питания? И т.д. и т.п. Одним словом Ынтерпрайз и капитализм.
> А если в подробностях - честно говоря, не хватило фантазии на цифру в 7000 компов.Я работаю в небольшой IT компании. Штат примерно 1200 человек. Компов примерно в полтора раза больше - у многих есть рабочие ноуты.
Количество железных серверов в нашем офисе (довольно малочисленном) около 15. Плюс зверюга поддержки виртуалок - на нем еще 20-30 серверов в виртуалках.
Всего офисов около 8.
Итого: пусть 1500 компьютеров + 8*50 = 400 серверов.
Управление все сети идет через политики и AD. Админов около 8 - по одному на офис. Справляются.
> Капитализм, мать его, культ потребления. Недавно вот мышь поменял девушке с PS/2 на USB так пришлось винду переставить чтоб заработало, т.к. винда навернулась а в бэкапе, сделанном PartImage'м из под Линуха не было установлено ни драйверов USB мыши (да, за пару недель до этого ещё и мышь накрылась), ни USB клавы.
> Предприятие серьёзное, но там явно не было столько компов, основная проблема сводилась к бухгалтерии (между прочим, проблема очень и очень объёмная)писали софт для Финской почтовой службы. Софт - одна из подсистем к их сортировочной машине (это та хрень, через которую проходит ВСЯ почта и потом на трейлерах разъезжается по городам и весям). Всего систем обеспечивающих работу около 5 или 6. Самые древние были сделаны лет 15-20 назад и работают. Наш софт вероятно еще лет 20 отработает прежде, чем появится задача по его смене на другой.
Часть систем написана на С (другого не было тогда), нанешние все на java.
PS система распознавания речи, она и сообщает работнику куда данное письмо нужно отсортировать.
ну 7000 это не предел.
Столько оказалось комппов на заводе ГАЗ, когда моя контора внедрила там Tivoli Configuration Manager.
Они даже не знали сколько у них компов реально есть, в каких цехах они установлены, кто является ответственным за каждый из компов.
Не говоря уже обо всём остальном. Еще на заводе Урал внедряли. Правда сколько там компов было не помню. =) Так что спрашивайте если интересно.Мониторинг тоже внедряли в одной из нефтедобывающих компаний. Но... там реально больше делали местные сотрудники... и из-за сложности инфраструктуры был целый зоопарк систем мониторинга, сообщения из которых агрегировались с помощью Tivoli Enterprise Console. (кстати еще один продукт, который применяется исключительно в так называемом Энтерпрайзе).
Я занимался системой отчетности, которая отображала собранный данные в виде графиков и таблиц.
А этот зоопарк как-то упорядочен был? Ну там зверушка в одном отделе, зверушка в другом, или так и управляют админы хламом?
У меня просто были неоднократно случаи когда пишешь что-то, а потом ещё несколько человек со своим стилем вклиниваются навешивать разные подсистемы, и когда на код потом смотришь - ощущение "don't touch running system" и поверить не можешь что это ты сам баран вот это всё спроектировал, т.к. в в голове совсем не так оно выглядело как в итоге получилось, даже и не близко. Ситуация ведь та же - зоопарк он и в африке зоопарк.
Я может отошёл от темы, но просто интересно, как с этой проблемой борятся в более крупных масштабах. Есть частные случаи, конечно - например, для разработчиков Drupal есть эдакий "принятый стиль кодинга", свой собственный. Ещё один частный случай - разработка ядра Linux. Здесь во-первых как и в случае с друпалом стиль оформления кода (или это мне приснилось :-)?), во-вторых жёстко выстроенная структура из людей, которые занимются аудитом кода/патчей и которая росла и строилась долгими годами в рамках одно проекта.
Насколько я понял, такие вещи как RHQ решают эту же проблему для сисадминов и глобально а не частным случаем, навязывая единый метод управления, который сводит на нет проблему (например) разного оформления config-файлов разными сисадминами? Мне вот приходилось принимать сервера у сисадминов которые покидали проект и для части сервисов нахрен поудалять все конфиги и настроить с нуля, причём по самым разным причинам (неработает/некрасиво/нифиганепонимаю).P.S. Поработал я как-то в фирме, внедряющей 1С и ощущение он ынтерпрайза "хлам он и в африке хлам, никакого единого решения не существует вобще никогда, эти решения сформировали только для того чтобы побыстрей да подороже впарить а потом ещё и заработать на переделывании этого решения в каждом частном случае".
P.P.S. Кстати, вот здесь, например:
http://www-01.ibm.com/software/tivoli/products/config-mgr/
как раз чёрным по белому написано что оно делает. В отличие от (например) вышеупомянутого JBoss. Без всяких innovative, scalable, integrated и прочего бла-бла-бла.
Ну там каждая система отвечала за мониторинг своей части инфраструктуры.
Т.е. например IBM Director (по-моему так называется) отвечал за сбор информации о состоянии бесперебойников, Tivoli Netview собирал информацию о состоянии корневых маршрутизаторов используя протокол SNMP (правда паршиво достаточно это делал.. но тем не менее делала) еще 2 или 3 системы... не IBM'овские в частности Microsoft SMS и еще какие-то продукты (сейчас уже не припомню, года 2-3 уже прошло, помоему GFI и еще какой-то продукт) собирали информацию о состоянии серверов. А потом все это валилось в Tivoli Enterprise Console через разные костыли.... и там на основе правил корректировалось. (т.е. например если одновременно отказал корневой маршрутизатор и перестали пинговаться часть серверов, то в TEC попадали и те и те события, а потом на основе правил собыстия о том что сервера не пингуются должны закрываться.... примерно так... а на основе этих данных уже админы получали некоторую общую картинку в самописной веб морде).А по поводу конфигурации... если бы использовались Java приложения (пусть и разных вендоров) конфиги с 90% вероятностью были бы в одном стиле.
В J2EE среде слава богу есть стандраты дефакто (например Spring Framework) и масса стандартов деюре, однако вендоры их придерживаются и разрабатывают совместно. См Java Community Process (JCP.org), на котором можно найти стандартные API для подавляющего большинства задач. И написав софт например под IBM'овский репозиторий контента (DB2CM или Filenet) этот же софт можно использовать например с Alfresco или Apache Jackrabbit. Конечно, какие-то правки все равно придется вносить, системы все равно в нюансах могут различаться, но API жестко зафиксирован. Тоже самое можно сказать про портлеты IBM Websphere Portlet Server, Liferay, Apache Jetspeed. И т.д. посмотри jcp.org там много всего интересного... жаль Oracle своими действиями подрывает этот порядок (нападки на Google, разборки с Apache Foundation).
Ммм, благодарю за ссылку, занятный ресурс. Особенно менюшка "JSR's" слева вверху - по сути это очень (ОЧЕНЬ!) хорошо рассортированная документация. Выбрав любую платформу сразу можно прикинуть список возможностей. Я, например, не знал что у некоторых версий J2ME есть USB API.
> Ммм, благодарю за ссылку, занятный ресурс. Особенно менюшка "JSR's" слева вверху -
> по сути это очень (ОЧЕНЬ!) хорошо рассортированная документация. Выбрав любую платформу
> сразу можно прикинуть список возможностей. Я, например, не знал что у
> некоторых версий J2ME есть USB API.=)) Да не за что. Рад, что ссылка оказалось полезной.
В рамках Java Community Process такие компании как Oracle, IBM, ранее был Apache и Google, Liferay и прочие договариваются о том какими будут общие API. Так что это первоисточник...
> Скажите, это просто мне не приходилось сталкиваться с этими Ынтерпрайз системами или у многих недоумение от шумихи этого странного муравейника?Большие системы это отдельный рынок отличающийся от малых. практически принципиально отличающийся. Админов учат и сами они учатся управлять одной системой, но добиваться в специфических режимах определенных возможностей. Скорости или отказоустойчивости или других вещей.
> Много в последнее время новостей о всяких JBoss или вот таких вот системах, но сколько я не ковырялся по сайтам и документации этих систем, так и не понял, где их применять. Из описаний ничего непонятно. Вобще ничего.
Это беда Java - низкий уровень вхождения в язык, но довольно высокий уровень вхождения в платформу. Слишком много различных направлений/течений/фреймворков и т.п. Фактически начиная проект с нуля нужно протестировать "а что нового и нужного изобрели за прошедшее время"
Еще одна особенность java - проекты "вечны". лично работал с проектами на системах, которые начали делать лет 15 назад. И с тех пор непрерывно улучшают/дописывают. Но не переписывают с нуля.
> Возьмите этот RHQ.
> Или вот например отрывок из описания JBoss:
> "market leading platform for innovative and scalable Java applications".Напрашивается вполне законный вопрос: "И шо? Ну Scalable, ну Innovative, ну Java. А что он делает?!! Функциональная нагрузка в чём заключается?"
Функциональная нагрузка JBoss это запуск и обеспечение работы JavaEE приложений.
Jboss обеспечивает проверку прав доступа на уровне вызова методов, доступ к БД, систему гарантированной доставки сообщений (типа AMQP, только намного раньше появился), управление многопоточностью, управление пулами сессионных объектов, работы веб-сервисов, управление запуском задач (типа cron только размазанный по всему кластеру - если указано, что задача выполняется только в один поток, то только одна нода кластера ее запустит), отказоустойчивость, кластеризацию. И это довольно малый список того, что ОБЯЗАН выполнять JavaEE сервер.
Поверх базовых возможностей JavaEE реализуются более высокоуровневые абстракции. Тот же ESB к примеру. На ESB строится работа любых государственных систем ибо слишком большие для прямой интеграции.
> Большинство из этого в последнее время всплывающего айсберга написано на Java. Может совпадение а может и нет. Может я ничего не понимю в религии Java?
Точно - не понимаешь ;)
На странице википедии, посвящённой ESB куча картинок Java, .NET и прочих заранее подготовленных компонентов. Всё это напоминает какое-то "ограничение диапазона поворота мыслей извне", банальную хорошо оплаченную рекламную компанию, т.к. в идее ESB никакой привязки к конкретным технологиям нет (или я слепой). То же самое, например, LAMP - ну почему не LNMP (nginx) или LHMP (lighttpd) или не BAMP (BSD)? Создаётся впечатление что энтерпрайз своими "решениями" реально ничего не решает, а алгоритм заработка сводится к следующим пунктам:1. Сформировать название для подхода который каждый день кто то использует но не задумывается об этом. Например, MVC - типичный пример. У любой серьёзной CMS есть отдельно натягивание шаблона, функциональное ядро и структура данных в БД. А ведь аббревиатура CMS наверняка раньше чем MVC.
2. Ненавязчиво в идею из п.1 в качестве компонентов подсунуть свои технологии и назвать их промышленным стандартом. Пример - LAMP. Да, пример не самый красочный, т.к. все технологии открыты и бесплатны, но этот пример тоже неплох если вспомнить на чём зарабатывают производители дистрибутивов. Поэтому как минимум буква L в аббревиатуре LAMP уже окупится.
3. Сформировать ещё 5-10 таких аббревиатур и назвать их "решения/solutions", аккуратно оформленный списочек из таких решений будет очень красочно смотреться на главной странице сайта компании.
4. Каждому клиенту впарить "готовое решение" а когда он поймёт (после внедрения) что оно ему не полностью подходит переписать часть "решения" под него, на чём немало заработать.Что бы мы имели без энтерпрайза: взяли несколько толковых специалистов, они провели аналитику работы предприятия, каждый по отдельному направлению сформировал список того что реально необходимо внедрить для решения каждой проблемы и в итоге они сформировали бы список технологий, которые необходимо внедрить и который будет иметь тот же функционал что и ентерпрайз. Разница в том что в случае ентерпрайза мы делаем 2 шага: внедряем и переделываем, а во втором случае - только один: внедрение. Кроме того, в случае ентерпрайза мы имеем дело с одной слжной и редкой системой, а во втором случае с несколькими простыми. Ну конечно же! На этом самом месте мы ещё и повышаем порог входа разработчиков в платформу, а ещё выше порог входа тех кто такие платформы/готовые_решения проектирует и избавляемся от тысяч потенциальных мелких фирмочек-конкурентов. В итоге остаются лишь несколько фирм, которым все кому надо потратить много денег доверяют как самым крутым специлистам в этом вопросе и платят больше денег. Капитализм в чистом виде: "да концентрации средств (денег и редких дорогих специалистов), нет конкуренции, нет развитию".
То же самое, например, LAMP - ну почему не LNMP (nginx) или LHMP (lighttpd) или не BAMP (BSD)?Потому что эта реализация технологий была первой. Linux был раньше BSD, Apache был сильно раньше энженикса и лайти, Perl а в последствии PHP были сильно раньше всего остального для Web. Аббревиатура еще прошлого века. И очень долго не было никакой альтернативы, никто не мог с ними конкурировать, даже MS стоял и курил в сторонке, да и сейчас.
>А ведь аббревиатура CMS наверняка раньше чем MVC
Это из репертуара "В огороде бузина, а в Киеве дядька". MVC это разделение кода для уровня представления и бизнес-логики, очень правильное разделение если что, зародилось еще со времен кобола, задолго до эпохи веб.
>Что бы мы имели без энтерпрайза: взяли несколько толковых специалистов, они провели аналитику работы предприятия, каждый по отдельному направлению сформировал список того что реально необходимо внедрить для решения каждой проблемы и в итоге они сформировали бы список технологий, которые необходимо внедрить и который будет иметь тот же функционал что и ентерпрайз.1. Энтерпрайз это где-то 80% решенных задач в любом случае сразу.
2. Самописное это практически всегда держится на 2-3 специалистов, случись что с ними предприятие встанет колом.
3. Несколько толковых специалистов никогда не заменят миллионы человеко-часов работы десятков тысяч специалистов.
4. Иногда предприятия нужно продавать, покупателю нужно понимать что он покупает.
5. Доработка в энтерпрайзе это готовая методология, выгони специалистов и найми других почти ничего не потеряешь.
6. Энтерпрайз повышает капитализацию предприятия, т.е. увеличивает как активы так и пассивы собственников.
> Потому что эта реализация технологий была первой.Согласен но это не есть хорошо, зато ситуацию описывает очень точно. Ведь Windows стал стандартом де-факто также. Он просто был одним из двух первых. А первым из двух стал только потому что продавался более грамотно чем Apple.
> Это из репертуара "В огороде бузина, а в Киеве дядька"
То что термин использоваться может не только в вебе не отменяет их взаимосвязи. Ведь бузина может попасть на рынок где дядька её купит и съест.
> зародилось еще со времен кобола, задолго до эпохи веб
Вполне возможно что здесь я оказался некомпетентен. Однако никогда ранее (в смысле давно) именно в вебе не слышал о MVC (возможно плохо слушал), из чего делаю всё тот же вывод: в вебе пользовались MVC до того как узнали что оказывается есть такая аббревиатура.
В любом случае MVC - частный случай, чё по нему холиварить-то?
> 1. Энтерпрайз это где-то 80% решенных задач в любом случае сразу.
Если бы! Я бы тогда такого не писал. Из того что я видел - цифра намного меньше. Каждый конечно видел именно и только то что он видел, а я наблюдал, повторюсь, совсем не 80%.
> 2. Самописное это практически всегда держится на 2-3 специалистов, случись что с ними предприятие встанет колом.Да!!! У меня сейчас та же проблема!!! И я не могу её решить, может я баран! Не могу и всё, борюсь уже год, а удалось только пару человек выдрессировать которым можно передать работу, а этого невероятно мало.
> 3. Несколько толковых специалистов никогда не заменят миллионы человеко-часов работы десятков тысяч специалистов.Видели сколько денег тратится на съёмку голливудского фильма? А сколько стоит истребитель F22 который собирают эти самые тысячи специалистов в нескольких штатах? А вот наши самолёты собирают весьма централизованно, результат достигается тот же или лучше при меньшем количестве специалистов и денег. Я не говорю что 2 человека заменят 10000, но вот 3000 могут и заменить 10000 если грамотно поставить процесс. Конечно, есть случаи когда оптимизировать просто некуда.
> 4. Иногда предприятия нужно продавать, покупателю нужно понимать что он покупает.Конечно. Но при покупке крупного предприятия специалисты в нём не заменяются. И проблемы здесь никакой нет. Вот если бы например Нокия купила Trolltech, всех нахрен уволила и поставила своих специалистов - это был бы ппц.
> 5. Доработка в энтерпрайзе это готовая методология, выгони специалистов и найми других почти ничего не потеряешь.Вот это мне и нравится, поэтому в последнее время и поглядываю на Java и прочие подобные технологии. См. мой коммент к п.2 и станет ясно что меня в этом вопросе мотивирует. Однако пока что на каждое "за" находится как минимум одно "против". В итоге я сейчас перехожу на всё что связано с языком haXe, т.к. сообщество именно минимального объёма и запросто можно общаться с разработчиками языка и всего что связано с платформой. Ставка не на масштаб ентерпрайза, а на информацию из первых рук. Посмотрите на ВВС Сербии, как их война научила. Их пилоты каждый день летают и каждый из них самый настоящий ас. Ставка на качество а не на количество - скорее потратят деньги на новую цистерну керосина чтоб пилоты могли летать и тренироваться а не на покупку нового самолёта. Хотя в 1999м у них не было ни качества ни количества, всего 12 самолётов против 600 пиндосских.
> 6. Энтерпрайз повышает капитализацию предприятия, т.е. увеличивает как активы так и пассивы собственников.Это для меня как для анархиста тема для холивара, здесь не удержусь и буду троллить. Всё это большой мыльный пузырь, всё временно. Настоящие активы - это сырьё, станки и золото. А бумажки - они и в африке бумажки.
> Потому что эта реализация технологий была первой. Linux был раньше BSDА! а! а! Раньше - где?
> Еще одна особенность java - проекты "вечны". лично работал с проектами на
> системах, которые начали делать лет 15 назад. И с тех пор
> непрерывно улучшают/дописывают. Но не переписывают с нуля.Проекты всегда вечны, привет от PMBOK. http://ru.wikipedia.org/wiki/Project_Management_Body_of_Know...
А то что на Java проекты не переписывают с нуля, это признак стабильности платформы.
С PMBOK знаком. Не самый лучший вариант, иягко говоря. Сам являюсь сторонником P2M.
А вот по поводу стабильности - на 200% соглашусь. Видимо, решения о добавлении нововведений 200 раз перепроверяются, так что потом не приходится ломать обратную совместимость версий платформы.
> А то что на Java проекты не переписывают с нуля, это признак стабильности платформы.ИМХО заблуждение (есть примеры из личной практики).
ЗЫ. Если так подходить почему все стремятся купить Форд/БМВ/Тайота/.... , а не ездят на жигулях ;)