1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый)
2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться)
3. Все взаимодействие между сервером и клиентами — через Web-сервисы
А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый) А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться) А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы
— Дорого в разработке (разнородные дефицитные специалисты нужны)
— Неочевидно, как типы данных и классы будут дружить. Вероятно, придется что-то дорабатывать в сериализации java-классов в поток SOAP и десериализации их из потока SOAP в NET
Re[2]: Покритикуйте несколько дерзкую архитектуру
От:
Аноним
Дата:
11.07.07 11:44
Оценка:
Здравствуйте, mike_sikalo, Вы писали:
_>Здравствуйте, Аноним, Вы писали:
_>- Дорого в разработке (разнородные дефицитные специалисты нужны)
К этому мы готовы.
_>- Неочевидно, как типы данных и классы будут дружить. Вероятно, придется что-то дорабатывать в сериализации java-классов в поток SOAP и десериализации их из потока SOAP в NET
а если писать web-сервисы, удовлетворяющие WS-1 Basic Profile 1.0 ???
Здравствуйте, 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-сервисы
Советую в таком случаи клиента писать на платформе 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-сервисы
При наличии ресурсов (Программистов 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-сервисы
Здравствуйте, Аноним, Вы писали:
А>1. На сервере — J2EE приложение на основе EJB 3 (сервер линуховый) А>2. На клиентах — .NET приложения на основе .NET Forms (не хочется со явовским Swing'ом связываться) А>3. Все взаимодействие между сервером и клиентами — через Web-сервисы
Поддерживаем сейчас такое приложение у клиента, постепенно мигрируя его полностью на нашу Java-систему. Очень неудобно отлаживать совместно клиент и сервер. Приходится постоянно следить за синхронностью стабов и т.п.
SWING для GUI, пожалуй, сейчас самая красивая система разработки, в нем самая хорошопродуманая архитектура. GUI-дизайнеров тоже полно, так что с ними проблем нет. По скорости Swing сейчас вполне адекватен — на тормозность интерфейса никто не жалуется.