Хм... а что такого монструозного в J2EE - Web Sphere та же в чистом виде саппортит эту платформу, и ничего. Это я про то, что J2EE или JSP (на чем-то типа TOMACAT`a) - с точки зрения производительности - не ужели будет разница? 

голословщина чистой воды, уж простите.

1. Вы полагаете, что для EjB over JNDI over Serialization и так далее не нужны дополнительные ресурсы? Вы мыслите категориями 10-летней давности когда библиотеки всевозмоного XML-related процессинга только появлялись и были естественно глюкавые и тормозные. Сейчас все иначе. c ~два месяца назад мы пронаблюдали как просто замена версии Xalan-а 3-х летней давности на последнию версию 2.7 увеличила производительность трансформации в 2.5 раза! да и уровень поддрежики стандартов уже совсем иной чем даже 3 года назад. К тому же вэбсервисы, это XML-binding, т.е. по определению максимально быстрый разбор. Например, родной сановский JAXB 2.0 это уже третье поколение это билиотеки, играл как раз с нею неделю назад - мощно. 

И вообще вы замерели производительность и ресурсоемкость вэбсервиса? как именно? какие билиотеки? где цифры? с чем сравнивалось? "требуют дополнительные ресурсы" - можно сказать про что угодно.

Да вэбсервисы не самая быстрая вещ, но уж простите не медленние CORBA и других техногих распределенных вычеслений и в разработке проще.

2.Axis ? Axis - отстой. мы написали единственный вэбсервис на Axis 1.1 и бросили его нафиг. у него были огромные пробемы с поддержкой W3C схем более сложной структуры, чем "примитивно". Да с тех пор вышло несколько версий, но в любом случае Axis однозначно не лучшая бибилиотека. просто по определенным причинам самая распространенная. И не нужна по одной не лучшей реализаия делать обобщающие выводы обо всей технологии. 

"Средства для разработки web services, такие как axis, не идеальны - в них есть и свои ограничения, и баги." это опять же знаете даже не смешно. я могу сказать "средства для рабоды с базами данных, как JDBC драйвера, не идеальны - в них есть и свои ограничения, и баги." и буду прав так же как и вы. 

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


3. Нет. нету никаких специфических трудностей в разработке и отладке вэб-сервиса. это просто: нарисавал схему, автоматически сгенерил классы, вписал спицифическую бизнесс-логику в одном месте. погонял тесты( иногда со снифером). все.

Ну и от себя добавлю, почему вэб-сервисы то? в чем приимущество? да в том что кто угодно и где угодно может доступиться. любой язык программированя, любая ОS, если ваша "песочница" поддерживает HTTP, то вы сможете работать с вэб сервисом начем бы он не был написан и где бы он стоял(даже долбанный Navision с полу-тыка поднял вэбсервис - хватанули какой-то ActiveX по умолчанию имеющийся в винде и реализующий SOAP и влет подрубились к вэбсервису написанному на java, как заставить Navision рабоать с CORBA или с хи-хи  EjB я даже думать не хочу ) 
 

ALKS, рад почитать такой супер-текст. Я вообще за максимально разумное использование стандартов, это делает софт продаваемым и профессиональным.

Хорошо, что нашелся сторонник веб-сервисов. Честно - совместимость - одно из преимуществ, на которое хочу сделать ставку.

Есть еще комменты - но пока не успеваю дописать. 

Сервер приложений, реализующий весь стандарт J2EE, ресурсов будет однозначно потреблять больше ресурсов, чем простой веб-контейнер по той простой причине, что у него намного больше сервисов, количество которых, впрочем, в большинстве случаев можно и сократить. В конечном счете это может, конечно, сказаться на производительности одного и того же приложения. Однако, в основном производительность будет зависеть от используемых технологий. EJB в сравнении с использованием какого-нибудь облегченного контейнера (Spring, например) плюс веб-сервисов (если нужны удаленные вызовы объектов) проиграет в производительности при сомнительных для большинства приложений достоинствах. Кроме того, разработка EJB ничуть не проще чем веб-сервиса.

ALKS действительно дело говорит, но технологий веб-сервисов, реализованных на Java, много и если предполагается взаимодействие только Java-2-Java, можно и чего-то полегче использовать. Хотя в конечном счете в простоте разработки особо не выиграете.

Websphere почти не пользовался. Во-первых, нет возможности его купить (я в бюджетной организации работаю), а во-вторых, просто не купил бы. ИМХО, если сравнивать Websphere с JBoss то, имея реализацию одного стандарта, во втором случае мы получаем поддержку огромного комьюнити, открытый исходный код, что само по себе достоинство, правда при менее качественной документации. Кроме того, JBoss не такой тяжелый. Используем JBoss уже 4 года, особых нареканий нет, с другой стороны и нагрузки на него выпадают не супер, поэтому как он будет себя вести при больших нагрузках на собственном опыте не знаю, только по рассказам. Рассказы в целом положительные. 

Вообще если бы у нас не было двух систем, реализованных с использованием EJB, скорее всего переехали бы на что-то более легкое, но вряд ли Tomcat по причине нереализованности у него некоторых сервисов, например, JNDI.

А технологический крен опять переместился от PHP к Java?   

Это сообщение отредактировал(а) tux - 25.4.2006, 13:48

по совему опыту скажу так если реч идет о серьезном приложении, ну скажем в несколько тысяч классов, то абстрагируясь от языка программирования и платформы... уже все бутет упираться именно и только в собственный код и "дизаин" собственной архитектуры. дорогой  и крутой АppServer поможет вам тут только в роли хромированного стального костыля по сравнению с деревянным: сломаеться по сравнению с деревянным позже, но сломаеться всё равно  и по опыту скажу что проблеммы в собсвенном коде встречаються на порядок чаше и решение их дает на порядок больший эфект чем любые танцы с бубном вокруг выбора аппликэйшн сервера.

Золотое правило тут как и везде - выбирайте то что лучше знаете, то с чем уже сталкивались....
Вот мы сидим на JRun 4. Он по большому счету... [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме] (простите искренне). но мы его знаем как облупленный, мы умеем его в тоностях настраивать, мы знает как конфигурить для него оптимально java машину, мы знаем его баги и умеем их обходить, у нас уже и контакты в группе разработчиков JRun и официальные бета-тестеры мы и-и-и-и .... и работает он только в путь под экстремальными нагрузками у нас. И не будем мы его менять хотя деньги для нас это вопрос даже не третий и знаем мы что WebLogic потонцеально много лучше 

P.S.
Websphere после моего опыта с её третей версией - только через мой труп. да наверное это субъективно очень и наверняка последние версии на уровне но... первое впечатление самое сильное  

Блин, здесь все зависит от народа. Есть народ - есть Java, нет народа - нет Java. Вообще - на PHP мы быстро напишем приемлемый вариант сайта, который решит 1/3 проблем.

Потом есть еще back-office, воспрос с выделенной клиентской базой, сервером анализа статистики, системой хранения и просей лабудой. Мы сменим лицо, наведем марафет, подоткнем силикона - но проблемы прочего софта реально останутся. На PHP, конечно, много можно сделать, но...



Это верно на 100% - такой подход дает прогнозируемые сроки. А сроки - крайне важный момент для любого бизнеса, и даже не столько их абсолютный размер, сколько прогнозируемость.

Фактически, команда разработчиков определит, что именно будем использовать.

Готов писать здесь некоторую хронологию развития событий.  =)))

Добавлено @ 16:05 


Процитирую моего товарища: Web Sphere 6 + Rational Application Developer - сильно упрощают работу.  Такой коктель совместно работает сильно эффективнее, чем Web Logic.

Добавлено @ 16:09 
А еще - я лично с сильным респектом отношусь к Rational - даже зная все кривости этого софта. Правильная весчь. В итоге получаешь и приемлемую документацию на архитектуру, и шаблоны классов, а как следствие - совпадение первого и последнего. 

А что такое Rational Application Developer? Была такая штука Rational Suite кажется, пакет приятнейших CASE иструментов $30000 инсталяция на 1 (одну) машину.... Знаю контору одну (точнее знал) которая разорилась попытавшись внедрить Rational Development Process c использованием этого пакета для проекта... и честно говоря не знаю ни одного случая где использование высокуровневх средств (ну UML иже с ним) "сильно упрощало работу". поднимает качество - да. позволяет организовать работу над гиганскими проектами с очень большим количеством разработчиков - да. но "упрощет"... увольте - увольте  

Будем разбирать по пунктикам 


Нужны, как и веб-сервисам. Изначально речь шла об одном проекте, в который собраются запихнуть веб-сервисы. EJB тоже никуда запихивать не надо  Если кто не заметил - Сан после второй версии понял, что не туда пошел и сделал EJB3.0 больше похожую на hibernate. Короче все это для большинства проектов дополнительный оверхед, ну и способ разработчикам поучить "крутые" технологии.


Можете еще в 3 раза увеличать, перейдя на XT, или в 5 используя libxslt  сравнение производительности. Я вовсе не предалагаю с++ использовать, просто показываю сколько лишней работы (WS) делается. Она конечно нужна для интеграции всего со всем, но излишня в одном проекте, технологическим развитием которого можно управлять.


Ну уж не простим, медленне  и понятно почему. Да и в разработке corba проще - пишешь интерфейс и реализуешь сгенеренный интерфейс. Все. Еще пара ссылочек чтобы не быть голословным: 
сравнение производительности
цитата оттуда

И вторая ссылка на обсуждение. Очень понравилось название  Веб-сервисы? Что курит индустрия? 

Добавлено @ 22:38 

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

Это сообщение отредактировал(а) jimur - 25.4.2006, 22:36

Нет, не прощу  Конечно, я написал без цифр или ссылок, но это вовсе не значит, что написанное взято с потолка - сравнение конечно проводилось. И не 10 лет назад .  Тесты выполнялись в контексте конкретного проекта, сравнивались ws(axis), rmi(sun), corba(sun), jms(activemq & joram) и сокеты. Резалты получались такие - rmi был быстрее ws практически на порядок. Ну и понятно, что сокеты вне конкуренции абсолютно (по скорости). Детали - версии софта, сценарии тестов, конкретные цифры и сами тесты готов представить. Но не сразу - их нужно или найти, или написать заново. И не то, и на другое нужно время, а его, увы, как-то не очень много  Если есть реальный интерес, то готов к началу следующей недели найти/восстановить и опубликовать. 


Ясное дело, что ресурсы нужны  для всего. Говоря про доп. ресурсы, я естественно имел в виду дополнительные ресурсы, по сравнению с RMI и прочими.
Готов согласится с тем, что сейчас возможно xml парсеры работают быстрее, чем год назад, но как-то сильно сомневаюсь, что существенно. Насчет XML binding и быстрого разбора - по любому это разбор текста. Вы же не будете спорить, что это гораздо более ресурсоемко, нежели разбор бинарных пакетов? 



Не согласен с утверждением про скорость(см. выше). + про аппаратные акселераторы для разбора XML и для XSLT слышал. Но не слышал про аппаратные акселераторы для CORBA/COM/DCOM. Может плохо слушал? Утверждение про "в разработке проще" более чем спорно. Мой опыт говорит об обратном. Хотя допускаю, что он у меня неправильный. 


Мой опыт работы с веб сервисами в java ограничивается Axis. Очень и очень согласен со словами "про огромные проблемы" и не только с поддержкой схем. С диагностикой ошибок тоже не все здорово. И с отладкой - но это, имхо, касается вообще SOAP. К сожалению, "по определенным причинам" мы использовали именно axis. Одной из таких причин является то, что Axis в силу своей распространенности является де факто стандартом  - это про выводы  Есть такие люди, которые называются заказчиками. Так вот они, зачастую, навязывают использование тех или иных фреймворков или технологий по тем или иным причинам. У нас вначале с axis было именно так. А потом привыкли к нему, его ограничениям и к исправлению багов в нем. 


Кгхм. Согласен, как то слишком обще получилось .  Скажу лишь, что имел в виду как раз те самые неочевидные ограничения со схемами/наследованием, про которые уже говорилось. Очень уж неприятные остались ощущения 

Для того, чтобы это был не мейн-стрим, нужно чтобы технология использовалась там, где это действительно необходимо, а не везде - по поводу и без. Пока это не так. То, что для многих задач веб сервисы штука очень полезная (даже и с axis) я не спорю. А про индустрию очень понравился заголовок топика, приведенный 
jimur, 
 )))


Снова почти согласен. Тока есть примеры, когда не все так уж и безоблачно. При взаимодействии с ws, написанными на java из Delphi были оченно существенные проблемы (предвидя заявления о голословности сразу скажу, что не помню но думаю, что гугл ту сможет прояснить ситуацию, по крайней мере мы в свое время натолкнулись на массу сообщений о проблемах, схожих с нашей - о5 же при передаче более-менее сложных типов данных). Повторюсь: использование ws, как и любой другой технологии, бывает оправдано, а бывает и нет. ws очень уж часто используются не к месту (имхо). Видел не один проект, где архитектор реализовал взаимодействие java - java (!) с помощью web services и все заканчивалось отказом от ws из-за глюков и проблем с производительностью. Знаю проект, где веб-сервисы были вроде и нужны - нужно было обеспечивать взаимодействие php-java. Закончился проект отказом от php и ws из-за многочисленных глюков. Все было переписано на jsp и java.   

ЗЫ Уважаемые админы, почините, плз мой старый логин pvo - пароль забыл, восстановление пароля не работает 

Добавлено @ 01:09 

Это вроде эклипс с набором айбиэмовских плагинов. По слухам довольно глючный. 

Это сообщение отредактировал(а) pvo1 - 26.4.2006, 01:07

Проблема с тем что люди не понимают что такое вэб сервисы и не рубят как их использовать есть. последний случая:
риск манаджмент система KQIS oт гиганской немецкой корпорации Karlstadt-Quelle это вэбсервис принимает xml из двух элементов: какой-то код и... xml c данными  - просто аут...

а вообще мы,  применяем активно вэбсервесы для ингерации разнородных систем. всевозможные синхронизации данных между чем попало, производительность не критична. будет он работать 0.5 секунд или 5 секунд для нас без разницы. 
Кроме того, как правило и грубо говоря, скоростью вызова метода и предачи параметров в компонент (буть то RMI, EjB, CORBA,вэб сервис или супер-сладно-кушистый-способ) можно смело пренебречь, собственно сама работа внутри занимает на порядки больше времени...

про CORBA я пожалуй спорить не буду, мой опыт ограничиваеться интеграцией LotusNotes 5 c чем-то там по CORBA. было трудно и дорого но было давно. 

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

Это сообщение отредактировал(а) ALKS - 26.4.2006, 12:00

Поддерживаю позицию pvo1, естественно, пользовать любую технологию (и не только) нужно по назначению.

Возвращаясь к топику, если мы принимаем решение для каждой части общего проекта писать софт на своих технологиях - например, сначала сайт на том, что есть - РНР, потом позже CRM - на более красивой платформе - Java, файловое хранилище - на C++.

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

А вот с этого места можно поподробнее? 
Делали тоже самое, тоже давно. Просто интересно как другие страдали тем же геморроем. Как в конце концов интегрировали, в паре предложений сам способ.


Не знаю, может быть XML-RPC? Протокол настолько простой, что там собственно и глючить-то не чему.  Хотя на практике Java-PHP не пробовал, только собирались как-то.

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

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


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



Выше упоминал про неудачный опыт разработки связки php - webservices(java). Не самый удачный вариант при наличии jsp, servlets и множества фреймворков для построения веб приложений.

Согласен.  

  

Это сообщение отредактировал(а) pvo1 - 26.4.2006, 14:48

Суммируя общую мысль, получем: 

•  идея веб-сервисов нормальная штука, и она может быть грамотным решением, особенно еси речь идет о SOA;
•  реализация - кривая и косая, и проще вообще все сделать самому;
•  реально специалистов, которые секут в такого рода техноогиях, немного, и в этом ж.

Иначе говоря, грамотная идея при сыроватой реализации.

All, объясните чайнику, как могут не работать совместно два приложения, в качестве протокола использующие стандартизованный XML-документ? Производители отклоняются от стандартов? 

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

Продукт, написанный на PHP, представляет меньшую технологическую ценность, чем софт, написанный на Java (субъективно - может у кого есть мнение на этот счет?).

В идеале, то, что мы пишем сейчас, переписать на Java позже. Это реально сдлеать, если разбить приложение на набор модулей или компонентов, между которыми существуют протоколы - то реально переписать одну часть, не повлияв на вторую. А тем более - если эти части физически живут на разных серверах. Это, к стати, наш случай.