Привет!
В Яве я новичок, но к сожалению имею достаточно большой опыт разработки интерпрайз-приложений на Делфи и именно эта зацикленность на других технологиях мешает мне понять, как поступить сейчас...

Имеем массовый, коммерческий продукт, написанный на Delphi с использованием фреймворка Remobjects + DataAbstract (надеюсь хоть кто-то тут о таком слышал В общем по структуре — трехзвенка, работает как с Oracle, так и с MSSQL (обязательное требование для продуктов такого типа). Последние тенденции рынка требуют выхода на кросс-платформенный уровень и кроме Явы я не вижу иных вариантов. К сожалению с Явой никто из команды не работал и найти опытных программистов на Яве у нас в городе не возможно (г. Кременчуг, кстати, кто хочет переехать — обращайтесь

Кросс-платформенность требуется только от сервера. Клиенты должны работать под Win32 так как они интегрируются с другими приложениями (shell extensions, office addins, etc.). По этому я ищу проверенную временем технологию, позволяющую программам, написанных на разных языках и в разных операционных системах взаимодействовать между собой.

На первый взгляд SOAP наиболее подходящая технология, но мы не нашли нормального способа сериализации датасетов с сервера и вообще не нашли никакого способа обрабатывать дельта-апдейты с клиентов. Есть подозрение, что Ява-разработчики используют вообще другой подход к работе с ремотными данными... Ну скажем сериализацию объектов мы используем, по этому я представляю о чем идет речь, но все равно часто приходится отображать данные в гридах, позволять пользователям их редактирование.

Чтение форумов указало на фреймворки Spring и Hibernate, но пока я сложно представляю, как они могут интегрироваться с другими платформами типа Delphi или .NET

CORBA?

Spring и Hibernate прямого отношения с интеграцией с не Java клиентами точно не имеют.
Первое — это IOC + навороты, а второе — ORM.

А не лучше ли вам использовать тот же кроссплатформенный Python или PHP может даже можно будет???
А то Java — это тяжелая артиллерия. Может быть очень сложно, особенно если будите много технологий юзать.

KD>А не лучше ли вам использовать тот же кроссплатформенный Python или PHP может даже можно будет???
KD>А то Java — это тяжелая артиллерия. Может быть очень сложно, особенно если будите много технологий юзать.

Боюсь что по Python мы найдем еще меньше информации и людей, а PHP — это только вэб-сервисы, слабая объектная модель... тот же вопрос — выгрузка датасета в XML и обратная загрузка изменений, сделанных пользователем.

KD>Spring и Hibernate прямого отношения с интеграцией с не Java клиентами точно не имеют.
KD>Первое — это IOC + навороты, а второе — ORM.

Собственно почему я и задаю вопросы. Все эти технологии оперируют объектами и их коллекциями, как происходит визуализация всего этого добра на клиенте? Как коллекция объектов может быть отображена и отредактирована в гриде? Каждое изменение свойства объекта провоцирует вызов на сервер или изменения состояний объектов коллекции может кешироваться на клиенте?

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

KD>CORBA?

Судя по статьям Игумнова в 2005м по CORBA еще не была готова спецификация По этому считаю эту технологию не проверенной временем.
Хотя может быть у кого-то был опыт ее использования?

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

T>В Яве я новичок, но к сожалению имею достаточно большой опыт разработки интерпрайз-приложений на Делфи и именно эта зацикленность на других технологиях мешает мне понять, как поступить сейчас...
T>Имеем массовый, коммерческий продукт, написанный на Delphi с использованием фреймворка Remobjects + DataAbstract (надеюсь хоть кто-то тут о таком слышал

Хмм, плохому танцору?
мешает не зацикленность на других технологиях, а зацикленность на конкретной библиотеке.
В вашем случае это Remobjects.
Remobjects сам по себе очень и очень неплохая библиотека, но он сам по себе.
Возможно, это лучший клон Java RMI для Delphi. Создавался и писался он именно с такой целью — сделать JavaRMI like remoting framework for Pascal.

Их море на самом деле — подобных библиотек, но Remobjects, повторюсь реально лучший и реально RAD.

T> В общем по структуре — трехзвенка, работает как с Oracle, так и с MSSQL (обязательное требование для продуктов такого типа).
Опять голословное утверждение. У других в требованиях будет стоять обязательным Firebird или как вот у товарища Уго Чавеса MySQL, укуси меня пчела

T> Последние тенденции рынка требуют выхода на кросс-платформенный уровень и кроме Явы я не вижу иных вариантов. К сожалению с Явой никто из команды не работал и найти опытных программистов на Яве у нас в городе не возможно (г. Кременчуг, кстати, кто хочет переехать — обращайтесь

В вашем случае это отнюдь не обязательно. Посмотрите на своего solution вендора, что он говорит: Delphi, FreePascal, NET(Mono).
Я конечно понимаю, что Delphi можно назвать кроссплатформенным только с большой натяжкой, за счет замороженного Kylix.
Но про FPC и Mono этого сказать нельзя.

Что понимаете под кроссплатформенностью, возможность запуска под каким-нибудь Linux или BSD дистрибутивом.
Ведь не под AIX же вы его запускать будете все равно там MS SQL нет (Sybase может быть, но если заточились на специфичные только для MS фенечки, то никак. Хинт: MS SQL это наследник Sybase и до 7 версии просто лицензировался MS).

Самый дешевый для вас вариант это взять тот же Remobjects и написать сервер на FPC или Mono. В пользу FPC — нативность, огромное количество платформ и возможно сохранить вложения в знания — ведь это тоже Pascal.

Иначе вы попадаете на переписывание ВСЕГО.
А если вы не врете, и у вас правда "массовый, коммерческий продукт", то для вас это смерти подобно.

T>Кросс-платформенность требуется только от сервера. Клиенты должны работать под Win32 так как они интегрируются с другими приложениями (shell extensions, office addins, etc.). По этому я ищу проверенную временем технологию, позволяющую программам, написанных на разных языках и в разных операционных системах взаимодействовать между собой.

(d)COM(+) при первом взгляде ограничен толко Windows, но есть реализация и под Linux.
CORBA — самая правильная вещь.
SOAP
свой протокол на базе XML

T>На первый взгляд SOAP наиболее подходящая технология, но мы не нашли нормального способа сериализации датасетов с сервера и вообще не нашли никакого способа обрабатывать дельта-апдейты с клиентов. Ну скажем сериализацию объектов мы используем, по этому я представляю о чем идет речь, но все равно часто приходится отображать данные в гридах, позволять пользователям их редактирование.

Без проблем на любых технологиях.
Скажем у меня есть в загашнике исходник на PHP прикидывающийся MIDAS сервером.

Или вот на прошлой работе, была именно такая связка Hibernate, Java App Server с хостингом в Tomcat на серверной стороне и Delphi на клиентской.
Общались они через XML over HTTP.

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

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

KD>>CORBA?

T>Судя по статьям Игумнова в 2005м по CORBA еще не была готова спецификация По этому считаю эту технологию не проверенной временем.
T>Хотя может быть у кого-то был опыт ее использования?


Я не знаю какие там книги что пишут, но CORBA это очень мощная, хотя и немножко и не простая, технология, которая используется как раз в тех ситуациях, которые ты сам описал.
Я сам её использовал в тиме, где стоимость проекта превышала 1 млн. $.

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

T>Судя по статьям Игумнова в 2005м по CORBA еще не была готова спецификация По этому считаю эту технологию не проверенной временем.
T>Хотя может быть у кого-то был опыт ее использования?

CORBA?
Не проверенная временем?

охр...ть дайте два

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

KD>>Spring и Hibernate прямого отношения с интеграцией с не Java клиентами точно не имеют.
KD>>Первое — это IOC + навороты, а второе — ORM.

T>Собственно почему я и задаю вопросы. Все эти технологии оперируют объектами и их коллекциями, как происходит визуализация всего этого добра на клиенте? Как коллекция объектов может быть отображена и отредактирована в гриде? Каждое изменение свойства объекта провоцирует вызов на сервер или изменения состояний объектов коллекции может кешироваться на клиенте?


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

Ещё раз: Spring и Hibernate — это реализация идей IOC и ORM. Изучи сами идеи!
Это не то, что тебе нужно для твоей задачи, но может понадобится для других. Но пока я не рекомендую даже думать об этих фреймворках, т.к. решить задачу можно и без них, а вам ещё нужно думать будет о многих других вещах.
Хибернейт можно попозже прикрутить, если все через DAO будите делать. Или пока можно взять попроще чем Хибер фреймворк
Apache IBATIS. На изучение IBATIS уйдет 15 минунт, на хибер может уйти месяц.

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

T> Клиенты должны работать под Win32 так как они интегрируются с другими приложениями (shell extensions, office addins, etc.).
Lamantine ?

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

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

T>>Судя по статьям Игумнова в 2005м по CORBA еще не была готова спецификация По этому считаю эту технологию не проверенной временем.
T>>Хотя может быть у кого-то был опыт ее использования?

glh>CORBA?
glh>Не проверенная временем?

glh>охр...ть дайте два

Да, насчёт CORBA — это перегиб. Её используют повсеместно на предприятиях: в банках, в медицине.

ИМНО у вас 3 варианта:

1. web services (SOAP)
2. CORBA (она кстати старая технология, которая уже умерла, но в общем то и делфи уже там и с делфи как раз будет работать, только вам нужны будут брокеры от Borlanda, а они очень дорогие. В любом случае спецов по ней вам найти будет еще сложнее)
3. Написать свой транспортный уровень.

На мой взгляд третий путь для вас наиболее реален. Мы в свое время организовывали связку C# и java и тоже написали свой транспортный уровень. Это не сложно и много времени не займет. Идея взята из CORBA. Есть некоторое описание удаленного метода (объекта) в любом удобном для вас синкаксисе (мы пользовались XML), из этого генерится серверная часть на указанном языке програмирования и клиентская. Все это связывается по TCP/IP и гоняет туда-сюда байты которые разбираются на нужной стороне.


P.S. web services конечно еще легче использовать, только надо понимать что это в любом случае мапинг бизнес объекта в XML и обратно, так что быстро это происходить не будет в любом случае. И если скорость для вас критична — то только третий путь.


Вячеслав Педак

V>2. CORBA (она кстати старая технология, которая уже умерла, но в общем то и делфи уже там и с делфи как раз будет работать, только вам нужны будут брокеры от Borlanda, а они очень дорогие. В любом случае спецов по ней вам найти будет еще сложнее)


Сейчас многие говорят, что С++ умер. Но если кто-то что-то говорит, это ещё не означает, что это так.
Поддержка CORBA обычно повсеместная: встроена в основные App-серверы.

TO tischenkoalex
А Клиенты у вас на Delphi?

Можно по HTTP попробовать: ваш сервер выставляет один сервлет, к которому обращаются приложения передавая http-query стринг для определения вызываемого объекта, а значения параметров в байт-потоке и vise versa. Правда CORBA во много быстрее работать будет, даже того же SOAP

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

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

glh>Возможно, это лучший клон Java RMI для Delphi. Создавался и писался он именно с такой целью — сделать JavaRMI like remoting framework for Pascal.
glh>Их море на самом деле — подобных библиотек, но Remobjects, повторюсь реально лучший и реально RAD.

Ни кто не спорит о RemObjects, просто пришло время переходить на кросс-платформенный уровень.

T>> В общем по структуре — трехзвенка, работает как с Oracle, так и с MSSQL (обязательное требование для продуктов такого типа).
glh>Опять голословное утверждение. У других в требованиях будет стоять обязательным Firebird или как вот у товарища Уго Чавеса MySQL, укуси меня пчела

Это не голословное утверждение, это стандартные требования к Records Management-продуктам. Было сказано к тому, что продукт должен путем конфигурирования переключаться между любой БД (в т.ч. обязательно MSSQL и Oracle).

T>> Последние тенденции рынка требуют выхода на кросс-платформенный уровень и кроме Явы я не вижу иных вариантов. К сожалению с Явой никто из команды не работал и найти опытных программистов на Яве у нас в городе не возможно (г. Кременчуг, кстати, кто хочет переехать — обращайтесь
glh>В вашем случае это отнюдь не обязательно. Посмотрите на своего solution вендора, что он говорит: Delphi, FreePascal, NET(Mono).
glh>Я конечно понимаю, что Delphi можно назвать кроссплатформенным только с большой натяжкой, за счет замороженного Kylix.
glh>Но про FPC и Mono этого сказать нельзя.

FPC и Mono — не хочу даже пытаться. Java был выбран как общепризнаный стандарт для энтерпрайз-приложений. Когда клиент спрашивает "на чем разработан продукт" он должен услышать ответ, который он ожидает услышать, это маркетинг.

glh>Что понимаете под кроссплатформенностью, возможность запуска под каким-нибудь Linux или BSD дистрибутивом.
glh>Ведь не под AIX же вы его запускать будете все равно там MS SQL нет (Sybase может быть, но если заточились на специфичные только для MS фенечки, то никак. Хинт: MS SQL это наследник Sybase и до 7 версии просто лицензировался MS).

BSD. А AIX и Linux то же возможны.
Дело в том, что часть клиентов предпочитает юниксовые системы, часть — виндовые. Продукт должен поддерживать обе, потому и требуется кросс-платформенность.

glh>Самый дешевый для вас вариант это взять тот же Remobjects и написать сервер на FPC или Mono. В пользу FPC — нативность, огромное количество платформ и возможно сохранить вложения в знания — ведь это тоже Pascal.

См. выше.

glh>Иначе вы попадаете на переписывание ВСЕГО.
glh>А если вы не врете, и у вас правда "массовый, коммерческий продукт", то для вас это смерти подобно.

Этот продукт (точнее линейка продуктов, использующих общий сервер) пережил переход из ДОС-версии на Windows. Должен перейти и на новый уровень

glh>(d)COM(+) при первом взгляде ограничен толко Windows, но есть реализация и под Linux.
glh>CORBA — самая правильная вещь.
glh>SOAP
glh>свой протокол на базе XML

Альтернативные реализации не хочется использовать и велосипед изобретать то же не хочется.

T>>На первый взгляд SOAP наиболее подходящая технология, но мы не нашли нормального способа сериализации датасетов с сервера и вообще не нашли никакого способа обрабатывать дельта-апдейты с клиентов. Ну скажем сериализацию объектов мы используем, по этому я представляю о чем идет речь, но все равно часто приходится отображать данные в гридах, позволять пользователям их редактирование.

glh>Без проблем на любых технологиях.
glh>Скажем у меня есть в загашнике исходник на PHP прикидывающийся MIDAS сервером.
glh>Или вот на прошлой работе, была именно такая связка Hibernate, Java App Server с хостингом в Tomcat на серверной стороне и Delphi на клиентской.
glh>Общались они через XML over HTTP.

Да я понимаю, что извернуться и написать это самому можно. Просто я думал, что есть стандартное решение, которое позволит скинуть полученный из базы данных рекордсет в XML, загрузить его на другом клиенте (скажем в TClientDataSet), отредактировать и закинуть дельту обратно на сервер.
Пока такого решения мы не нашли. Разве что CORBA?

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

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

T>> Клиенты должны работать под Win32 так как они интегрируются с другими приложениями (shell extensions, office addins, etc.).
glh>Lamantine ?

Ну да

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

T>В Яве я новичок, но к сожалению имею достаточно большой опыт разработки интерпрайз-приложений на Делфи и именно эта зацикленность на других технологиях мешает мне понять, как поступить сейчас...

имхо, если у вас присутствует ярко выраженная направленность на решение бизнес-задач и проблем предметной области, то надо брать CORBA от Borland, максимально использовать потенциал своей команды на Delphi в качестве клиентов, и осваивать серверные возможности борландического аппсервера

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

T>На первый взгляд SOAP наиболее подходящая технология, но мы не нашли нормального способа сериализации датасетов с сервера и вообще не нашли никакого способа обрабатывать дельта-апдейты с клиентов. Есть подозрение, что Ява-разработчики используют вообще другой подход к работе с ремотными данными... Ну скажем сериализацию объектов мы используем, по этому я представляю о чем идет речь, но все равно часто приходится отображать данные в гридах, позволять пользователям их редактирование.

насчёт датасетов вам придётся коренным образом менять как своё представление об этом, так и ломать представления ваших пользователей.
это не есть проблема delphi или другого языка. это проблема правильной консолидации вычислительных ресурсов, согласно которой тягать туда-сюда, рендерить и проч. большие (табличные) объёмы данных ни к чему, если из них пользователь скроллингом находит через полчаса нужную строку и правит в ней один байт.
таблицы надо делать короткими, формы запроса данных для последующего измеения — максимально удобными, чтобы пользователь мог легко с помощью фильтрации найти то, что нужно без скроллирования датасетов... в-общем, это отдельная тема для разговора

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

T>Собственно почему я и задаю вопросы. Все эти технологии оперируют объектами и их коллекциями, как происходит визуализация всего этого добра на клиенте?
А в чем сложность показать данные из объекта?

T>Как коллекция объектов может быть отображена и отредактирована в гриде?
Какая-то люая коллекция любых объектов, например через Reflection. Но лучше через технологию JavaBeans. Только у вас же клиент на другой платформе. В Delphi нет рефликсии? Не верю.

T>Каждое изменение свойства объекта провоцирует вызов на сервер или изменения состояний объектов коллекции может кешироваться на клиенте?
Кешировать? Я вообще не улалвливаю ход мысли. Сервер отдал коллекцию, клиент сделал с ней все что хочется и отдал серверу.

Все остальное конкретные детали конкретных реализаций. Хочется распределенных объектов — это тоже можно организовать.