jimur, спасибо за линк про курение, мысли там дельные есть  а что еще более ценно там есть другие линки 

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

deadrat, ты зриш в корень, насчет стандартов. первая проблема - не все одинаково хорошо поддерживают XML схемы, на которых основан WSDL(http://www.w3.org/TR/wsdl), так что далеко не всекий вебсервисный врейм-ворк способен сожрать достаточно сложную схему... с наследованием например и прочими "фишками."  во-вторых SOAP это отдельная история - вот тут любопытненькая статейка (http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html) почитаёте может что-то проянит  

ok.

У меня есть вопрос - чем вы пользуетесь для имплементации вебсервисов? 

В итоге получаете кучу рисков по проекту, т.к. риск IT проекта есть функция от числа технологий. 

Практически все задачи эффективно решаются на Java, иногда, если нужна большая производительность допустимо использование нативного кода. 

Кроме того, используя разныю технологии вы можете получить:
1. несколько групп полуспециалистов в каждой технологии
2. внутренние конфликты типа php рулит, jsp отстой

Использование единой платформы позволит:
1. использовать более эффективные технологии взаимодействия подсистем
2. получить меньше глюков при взаимодействии
3. создать команду профессионалов 

Все это конечно очевидно, только вот вся дискуссия как раз и началась из-за того, что последнее-то и не получается. Можно конечно взять вчерашних (или сегодняшних) студентов (как вариант переучить php-истов на Java, впрочем им-то от этого только лучше будет), они будут работать в процессе обучения и в конце концов вырастут в специалистов. Только вот проблема, это процесс длительный. Мне, впрочем, так и приходится поступать поскольку другого выхода нет - готовых специалистов по Java в Бурятии взять негде. Но у меня условия другие, сроки не жесткие. А у deadrat возможности ждать результата я думаю не будет. 

Кроме быстрого старта нужно еще и думать о будущем


Ага, вот и оставить потом такого менеджера наедине с "радостными" программистами, переписывающими чье-то детище c php на Java  
 

Не просек причину сарказма - согласен, что переписывать чужой код - задача просто из ряда вон. Но идея не в переписывании софта с одного языка на другой, а в разработку новой версии. То есть, дано: разработанная архитектура, написанный на PHP код, накопленный опыт. Задача: написать вторую версию, но на Java.




Thanx tux, именно в сроках одно из ограничений. 
 

http://java.sun.com/webservices/jwsdp/index.jsp

только мы пользуемся версией 1.3, версия 2 требует Java 5 на которую мы пока перевести наши приложения не можем.
хочется сказать что jwsdp 2 включает JAXB 2, который по моему мнению, просто прорыв и в области поддержки XML схем и не только. 

Объясняю. 
Я считаю этот подход: сейчас пришем на этом, а потом пишем на том неверным.
По следующим причинам:
1. Разработчики на PHP будут писать все в мусорную корзину
2. Разработчики на Java вместо создания нового, интересного проекта будут переделывать существующее барахло (а иначе зачем переделывать)
3. Будет неоправданное двойное расходование бюджета на изучение/освоение предметной области сначала php-, а потом и java- разработчиками

З.Ы. разработчики это не ресурс, а человеческий фактор  

Согласен с этим утверждением, но не согласен с причинами 1и 2. 

1. Разработчикам на PHP не обязательно знать, что они занимаются разработкой тупиковой ветви проекта. Кроме того есть небольшая вероятность того, что из этой связки получиться что-нибудь хорошее. Такое, что можно будет потом развивать, а не переписывать.
2. После эксплуатации того, что будет написано, возникнет куча предложений по усовершенствованию веб приложения. И очень вероятно, что java версия будет лучше php-ной. А когда люди понимают, что они сделали что-то, что лучше того, что было раньше, то это неплохо их стимулирует.

ну и по п. 3. Бывает, что если ты быстро делаешь макет/1 версию/... тебе выделяют бюджет. Если не делаешь - сидишь на бобах. Тут может быть именно такой случай. 

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

ИМХО в любом случае лучше, чем ждать когда соберется команда java-программеров и уже вместе с ними начинать работу. Может быть до тех пор и кто-то с Винграда созреет для участия.  

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

Существуют чисто рыночные факторы, которые не касаются красоты разработки. Гениальный проект не представляет ээ... дифференциальной ценности. А в любом бизнесе - воспрос денег - вопрос времени, и все нужно здесь и сейчас. А в инете быть вторым - быть последним, а быть третьим - быть никем.

По этой причине мы сознательно пойдем на выбор той платформы, на которой сможем написать все быстро. 




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

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

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


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

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

Но вопрос возможностей платформы уже больно бьёт ключем: Workflow-сервер, к примеру, должен отправить запрос серверу обработки на асинхронную подготовку данных, а потом получить ответ, что данные готовы. По ходу, JMS (может, ошибаюсь - не спец пока). А у нас - PHP.... будем думать, как быть =)) 

Back to topic - по ходу, платформа - то, что придумали программеры. Определяет то, на сколько много усилий и мозгов нужно будет приложить для того, чтобы получить качественный продукт. Чем меньше усилий и мозгов, то есть чем навороченнее платформа - тем дороже специалисты. Чем банальнее платформа - тем дешевле специалисты, больше соплей, неколенных решений, изобретенных велосипедов и т.п. 

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

стоимость спеца практически не зависит от того в чем он спец, зависит от того какой он спец. эксперт  глубоко разбирающийся в том же PHP и имеющий 10 лет опыта за спеной стоит ни чуть не меньше хорошего специалиста Java. 

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