Здравствуйте, Аноним, Вы писали:

А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы
Поддерживаем сейчас такое приложение у клиента, постепенно мигрируя его полностью на нашу Java-систему. Очень неудобно отлаживать совместно клиент и сервер. Приходится постоянно следить за синхронностью стабов и т.п.

SWING для GUI, пожалуй, сейчас самая красивая система разработки, в нем самая хорошопродуманая архитектура. GUI-дизайнеров тоже полно, так что с ними проблем нет. По скорости Swing сейчас вполне адекватен — на тормозность интерфейса никто не жалуется.

Здравствуйте, Аноним, Вы писали:


А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

Советую в таком случаи клиента писать на платформе Eclipse Java (RPC, SWT) он будет быстрее Swing'го ...

Здравствуйте, Stormblast, Вы писали:

S>Здравствуйте, Аноним, Вы писали:


А>>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

S>Советую в таком случаи клиента писать на платформе Eclipse Java (RPC, SWT) он будет быстрее Swing'го ...

проблема с явовскими клиентами (Swing и SWT) не в скорости, а в количестве и качестве элементов управления, а также в удобстве рисования, программирования и последующей поддержке графических форм.

Здравствуйте, Аноним, Вы писали:


А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы


— Дорого в разработке (разнородные дефицитные специалисты нужны)
— Неочевидно, как типы данных и классы будут дружить. Вероятно, придется что-то дорабатывать в сериализации java-классов в поток SOAP и десериализации их из потока SOAP в NET

Здравствуйте, mike_sikalo, Вы писали:

А>>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

Особо дерзкого ничего нет. Работать будет

_>- Дорого в разработке (разнородные дефицитные специалисты нужны)

Вобщем то гуевые java программисты тоже сами по себе редкость да и возможности java GUI не то чтоб впечатляют. Так что резонов придумать можно. Этот момент в форуме невозможно оценить. Хотя надо признать что "неохота связываться" недостаточно веский аргумент

_>- Неочевидно, как типы данных и классы будут дружить. Вероятно, придется что-то дорабатывать в сериализации java-классов в поток SOAP и десериализации их из потока SOAP в NET

Тут как раз более менее понятно. Делаем WSDL и генерим по ней классы и там и там.

1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
3. Все взаимодействие между сервером и клиентами — через Web-сервисы

Здравствуйте, mike_sikalo, Вы писали:

_>Здравствуйте, Аноним, Вы писали:


_>- Дорого в разработке (разнородные дефицитные специалисты нужны)

К этому мы готовы.

_>- Неочевидно, как типы данных и классы будут дружить. Вероятно, придется что-то дорабатывать в сериализации java-классов в поток SOAP и десериализации их из потока SOAP в NET

а если писать web-сервисы, удовлетворяющие WS-1 Basic Profile 1.0 ???

Здравствуйте, <Аноним>, Вы писали:

А>не хочется со явовским Swing'ом связываться
Почему?

Здравствуйте, <Аноним>, Вы писали:


А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

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

А вот при переходе на конкретику могут возникать уже свои "НО". В зависимости от "токости" клиента, того какие данные и в каком виде должны передаваться и т.п.

Здравствуйте, <Аноним>, Вы писали:

А>проблема с явовскими клиентами (Swing и SWT) не в скорости, а в количестве и качестве элементов управления, а также в удобстве рисования, программирования и последующей поддержке графических форм.
Научите программистов не рисовать одноразовый ГИП, а проектировать — тогда поддерживать его будет значительно проще.
Тем паче под Eclipse есть рисовалка — Eclipse Visual Editor (поддерживает и SWT, и Swing), так что проблем с накидыванием формочек в стиле Delphi вроде нет... только зачем?

Гм... Только из-за этого делать систему разнородной... Сдал недавно клиент-сервер: SOAP веб-сервис на PHP5, SOAP-клиент на .NET C# 2.0 — нестыковок по SOAP было мало, но тем не менее, если выбирал бы технологии сам, предпочел однородность.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Stormblast, Вы писали:

S>>Здравствуйте, Аноним, Вы писали:


А>>>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>>>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>>>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

S>>Советую в таком случаи клиента писать на платформе Eclipse Java (RPC, SWT) он будет быстрее Swing'го ...

А>проблема с явовскими клиентами (Swing и SWT) не в скорости, а в количестве и качестве элементов управления, а также в удобстве рисования, программирования и последующей поддержке графических форм.

Тоже не соглашусь, дешевле использовать имеющиеся человеческие ресурсы (т.е. можно перекинуть на гуи остальных джава програмеров) для написания пары нестандартных контролов, да и архитектура SWT, RPC мне больше нравиться чем в .net, да нет привязки к одной OC — windows ...
на мой взгляд весомых плюсов больше !

Здравствуйте, Аноним, Вы писали:

А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы

Технически — проблем никаких нет. Следовательно, остается два аспекта: ресурсы вашей компании и перспективы развития проекта. А вообще, я бы рекомендовал сделать четыре столбика для возможных сочетаний ServerSide и ClientSide и выписал бы плюсы и минусы каждого подхода. После этого можно провести более-менее объективное сравнение и выбрать оптимальный вариант для вашей задачи.

Здравствуйте, Аноним, Вы писали:


А>проблема с явовскими клиентами (Swing и SWT) не в скорости, а в количестве и качестве элементов управления, а также в удобстве рисования, программирования и последующей поддержке графических форм.

На жаваскрипте такие финты выделывают, а ты говоришь Swing не справится.
SWT вообще ничем не отличается от обычных приложений виндовых, т.к. и использует виндовые контролы.
Swing благодаря тому, что не использует конторы ОС, а сам их отрисовывает как раз и будет мощнее любого API — взял кнопку, переопределил метод painComponent, и рисуй что хочешь вместо её стандартного вида.
Поэтому так и скажи — не знаю свинг, и не хочу с ним разбираться.

Человека, разрабатывающего ГУЙ в случае чего можно кинуть на серверную часть, потому как он в курсе предметной области, и наоборот. А если там и там технологии будут разные, с этим будет трабл. Я например свой еклипс ни на какую студию не променяю

Здравствуйте, Аноним, Вы писали:


А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы


в догонку почитайте, вроде интересно :)

Здравствуйте, GarryIV, Вы писали:

GIV>Вобщем то гуевые java программисты тоже сами по себе редкость да и возможности java GUI не то чтоб впечатляют.

Возможности Java GUI, ИМХО, если не брать в расчет WPF, значительно больше онных в .NET.