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

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

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

Использование Mono, имхо, будет капец.
Mono кем стадартизирован? Да и .NET — закрытая платформа, i.e. нет Microsoft — нет и .NET.
А J2EE — это набор спецификаций и куча мощных вендоров: IBM WebSphere, BEA WebLogic, Oracle App Server, Sybase App Server etc.

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

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

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

Спорное утверждение
1) то, что с технологией или инструментом перестают носиться студенты или их преподаватели или менеждеры ориентирующиеся только по рекламным брошуркам, не говорит о ее умирании. (Был один знакомый преподаватель, который после нескольких лет вдруг открыл, что массивы в С могут быть не только одномерными.)
Есть разница, между "горячими" штучками и промышленным производством. Я прекрасно помню всю шумиху с Java в районе 96 года. И что, прошло время и она заняла свою нишу, причем несколько не ту какую ей прочили маркетологи (Не путать с создателями и программистами).

Есть мнение, и я его разделяю, что Java — лучшая платформа реализации серверов, а Delphi — Win клиентов.
В настоящем времени.
NET пока нервно курит в сторонке.

2) есть 2 замечательных opensource брокера реализованных на Delphi — mtORB и dORB.

V>3. Написать свой транспортный уровень.

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

Ох уж это изобретение велосипедов...

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

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

Давайте тогда уж говорить честно, что поддержка IIOP (вернее даже RMI-IIOP т.е. возможности гонять джавные RMI вызовы по корбовскому транпорту) — это да, это есть в большинстве J2EE серверов. Только если вы реально попробуете через корбу (т.е. например из Delphi) дернуть ждава бин из этого сервера, то вы узнаете что сделать это ой как не легко (если вообще возможно).

И уж если говорить про сервисы корбы которые нужны типа транзакционности и т.д., то это может обеспечить только CORBA брокер и они не поддерживаются джавным сервером приложений (в смысле корбовских сервисов которые можно использовать из pure CORBA приложений)

А корба умерла, к сожаленью, никто на корбе новые приложения не пишет...


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

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

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

Ну даже возразить нечего

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

glh>>Самый дешевый для вас вариант это взять тот же Remobjects и написать сервер на FPC или Mono. В пользу FPC — нативность, огромное количество платформ и возможно сохранить вложения в знания — ведь это тоже Pascal.
T>См. выше.
glh>>Иначе вы попадаете на переписывание ВСЕГО.
glh>>А если вы не врете, и у вас правда "массовый, коммерческий продукт", то для вас это смерти подобно.
T>Этот продукт (точнее линейка продуктов, использующих общий сервер) пережил переход из ДОС-версии на Windows. Должен перейти и на новый уровень

Если вам за это заплатят, то вперед. Java на сервере это прелесть как хорошо.

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

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

CORBA и Java — братья навек!
Потому как RMI — Java only solution, что опять же резко окраничивает сферу применения — интероперабельности с другими платформами разработки нет — толко через шлюзы.


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

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

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

Ну все-таки не смешивай в одну кучу яблоки и помидоры.
Хочешь работать на Java с Borland ClientDataset DataPacket — JBuilder в руки и выкавыривай оттуда класс, это реализующий. Он ЭТО умеет.
Даже в примерах есть.

ClientDataset — это решение 1 вендора — Borland.

T>Разве что CORBA?

CORBA предоставляет тебе транспорт и инфраструктурные сервисы не зависящие ни от платформы, ни от производителя.

Также как XML или HTTP не виноваты в том, что чего-то не умеют, это просто инструменты.

Научить их чему-либо, наша задача.

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

glh>Спорное утверждение
glh>1) то, что с технологией или инструментом перестают носиться студенты или их преподаватели или менеждеры ориентирующиеся только по рекламным брошуркам, не говорит о ее умирании. (Был один знакомый преподаватель, который после нескольких лет вдруг открыл, что массивы в С могут быть не только одномерными.)
glh>Есть разница, между "горячими" штучками и промышленным производством. Я прекрасно помню всю шумиху с Java в районе 96 года. И что, прошло время и она заняла свою нишу, причем несколько не ту какую ей прочили маркетологи (Не путать с создателями и программистами).


Я готов согласиться про студентов и преподавателей, но вот когда маркетологи перестают "носиться" с технологией — она умирает. Хочется вам этого или нет. В качестве домашнего упражнения предлагаю привести примеры систем которые написаны с использованием CORBA и разработаны недавно... А вот подобных систем написанных на веб сервисах — полно.


glh>Есть мнение, и я его разделяю, что Java — лучшая платформа реализации серверов, а Delphi — Win клиентов.
glh>В настоящем времени.
glh>NET пока нервно курит в сторонке.

Вы извините в каком мире живете? На Delphi в мире пишут единичные коммерческие системы, а на C# — куча.


glh>Ох уж это изобретение велосипедов...

ну дак научите как сделать лучше? Раскажите какой брокер лучше использовать в коммерческой системе которая пересылает 1000 сообщений в минуту (хотя бы), как на C# работать с ним и т.д.

Ох уж мне эти теоретики...


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

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

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

Вы забыли только добавить сколько стоит такой софт Насколько я помню борландовский сервер надо от $5000 минимум считать начинать? И кстати в свете последних изменений в Борланде — вы действительно думаете что российской компании стоит связывать свою судьбу с борландом? То, что они закрыли офис в России и вам хрен кто поддержку окажет вас не пугает?


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

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

V>Здравствуйте, KievDeveloper, Вы писали:
джавным сервером приложений (в смысле корбовских сервисов которые можно использовать из pure CORBA приложений)

V>А корба умерла, к сожаленью, никто на корбе новые приложения не пишет...

Ага, только что тогда на масштабных предприятиях используют? SOAP? Не всегда. В основном это CORBA.
Я бы не говорил, что корба умерла, т.к. она как раз не умерла, а даже развивается.
Она сложна — да, это правда, поэтому она "умерла" для мелких проектов.

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

V>А корба умерла, к сожаленью, никто на корбе новые приложения не пишет...

Где в новых книжках упоминания о ней?
Везде SOAP.

Многие неофиты не знают элементарных вещей!

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

Люди без ORM маппера не умеют работать с БД!

Для дерганья малюсенькой функции OC ищут готовый компонент.

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

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

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

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

V>Вы забыли только добавить сколько стоит такой софт Насколько я помню борландовский сервер надо от $5000 минимум считать начинать? И кстати в свете последних изменений в Борланде — вы действительно думаете что российской компании стоит связывать свою судьбу с борландом? То, что они закрыли офис в России и вам хрен кто поддержку окажет вас не пугает?


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


tischenkoalex, однозначно переписывайте клиенты тоже на Python. Borland и Delphi — прошлый век. Стоимость Delphi программистов сейчас резко падает и они мало кому нужны.

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

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

V>>А корба умерла, к сожаленью, никто на корбе новые приложения не пишет...

glh>Где в новых книжках упоминания о ней?
glh>Везде SOAP.

Всё правильно, с корбой разбираются спецы, которым у туториала хватит.
Корба однозначно для ентерпрайз решений. А таких намного меньше, чем обычных сайтов с SOAP
Кстати, Enterprise Java Beans (EJB) используют CORBA как бекэнд.

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

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

V>Вы забыли только добавить сколько стоит такой софт Насколько я помню борландовский сервер надо от $5000 минимум считать начинать? И кстати в свете последних изменений в Борланде — вы действительно думаете что российской компании стоит связывать свою судьбу с борландом? То, что они закрыли офис в России и вам хрен кто поддержку окажет вас не пугает?

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

использовать продукты Borland, BEA, Oracle, Jboss и проч — всё это, конечно, выбор. и, хорошо, что не мне его делать в конкретном случае речь лишь про некоторый выигрыш, который можно получить на повторно используемом опыте команды в delphi-технологиях. не более того. если они там случайно выяснят обратное, то просто больший выбор получат

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

ps. если в целом абстрагироваться от delphi, то имхо лучше иметь продукт с открытым кодом, чем закрытым. т.е. jboss лучше, чем borland, bea, oracle... но в контексте команды, опытной только в delphi этот фактор далёк от ключевых

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

KD>tischenkoalex, однозначно переписывайте клиенты тоже на Python. Borland и Delphi — прошлый век. Стоимость Delphi программистов сейчас резко падает и они мало кому нужны.
Может хватит бред про Python нести? Надоело уже..

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

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

KD>>tischenkoalex, однозначно переписывайте клиенты тоже на Python. Borland и Delphi — прошлый век. Стоимость Delphi программистов сейчас резко падает и они мало кому нужны.
C>Может хватит бред про Python нести? Надоело уже..

Ну, ну.. расскажи почему кроссплатформенный Python — это бред? Будет интересно послушать мнение Гуру. бугага

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

C>>Может хватит бред про Python нести? Надоело уже..
KD>Ну, ну.. расскажи почему кроссплатформенный Python — это бред? Будет интересно послушать мнение Гуру. бугага
Тем, что тогда придется делать интерфейс командной строки. В самом Питоне графических сред никаких нет.

Ну и уж проще тогда взять Java+SWING/SWT и не мучаться с интерфейсом к серверу приложений из другого языка.

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

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

T>Имеем массовый, коммерческий продукт, написанный на Delphi с использованием фреймворка Remobjects + DataAbstract (надеюсь хоть кто-то тут о таком слышал В общем по структуре — трехзвенка, работает как с Oracle, так и с MSSQL (обязательное требование для продуктов такого типа).
А мы потихоньку пишем RemObject for Java на базе Spring Remoting..

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

B> В Delphi нет рефликсии? Не верю.
Ну если только так WriteProcessMemory Function для не .net

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

D_T>А мы потихоньку пишем RemObject for Java на базе Spring Remoting..

Те будет совместимо с оригиналом и полностью интероперабельно? +

Или просто "like" ? жирный -

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

glh>>Спорное утверждение
glh>>1) то, что с технологией или инструментом перестают носиться студенты или их преподаватели или менеждеры ориентирующиеся только по рекламным брошуркам, не говорит о ее умирании. (Был один знакомый преподаватель, который после нескольких лет вдруг открыл, что массивы в С могут быть не только одномерными.)
glh>>Есть разница, между "горячими" штучками и промышленным производством. Я прекрасно помню всю шумиху с Java в районе 96 года. И что, прошло время и она заняла свою нишу, причем несколько не ту какую ей прочили маркетологи (Не путать с создателями и программистами).

V>Я готов согласиться про студентов и преподавателей, но вот когда маркетологи перестают "носиться" с технологией — она умирает. Хочется вам этого или нет. В качестве домашнего упражнения предлагаю привести примеры систем которые написаны с использованием CORBA и разработаны недавно... А вот подобных систем написанных на веб сервисах — полно.

glh>>Есть мнение, и я его разделяю, что Java — лучшая платформа реализации серверов, а Delphi — Win клиентов.
glh>>В настоящем времени.
glh>>NET пока нервно курит в сторонке.

V>Вы извините в каком мире живете? На Delphi в мире пишут единичные коммерческие системы, а на C# — куча.

Ну Вы наверное просто в том числе и на С# пишете, потому так и говорите — своя рубашка ближе к телу.

Я, напротив, примерно уже с год как наблюдаю некоторое отврезвление.
Зарплаты на NET просели, проекты в основной массе однотипные.

Плюс, не забывайте о факторе массовости и/или моды.
Там где массовость — там низкая квалификация, студенты и прочие "индусы".

V>ну дак научите как сделать лучше? Раскажите какой брокер лучше использовать в коммерческой системе которая пересылает 1000 сообщений в минуту (хотя бы), как на C# работать с ним и т.д.

Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP.
Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.

Естественно возникают трудности при работе с технологией, которые вынужденны решать разработчики.
Либо сами, либо с помошью третьих вендоров. В частности у Borland было решение CORBA для NET, Ethera кажеться.

Может быть он его уже интегрировали в VisiBroker — "Fully compliant with the CORBA 2.6 specification and beyond, VisiBroker supports development in Java, C++ and .NET languages, including Microsoft C++ and C#".

PS. У нас в организации есть проекты и на NET(Сs) и на Java и на Win32(CB&Delphi).

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

glh>Здравствуйте, Denis_TST, Вы писали:
D_T>>А мы потихоньку пишем RemObject for Java на базе Spring Remoting..
glh>Те будет совместимо с оригиналом и полностью интероперабельно?
Полностью нам не надо, для начла достаточно только тех типов котрые есть и в Delphi и в java.
Делаем только бинарный формат передачи, и только серверную часть — в этом случае не так уж и
много нужно писать нового...

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

KD>Ага, только что тогда на масштабных предприятиях используют? SOAP? Не всегда. В основном это CORBA.
KD>Я бы не говорил, что корба умерла, т.к. она как раз не умерла, а даже развивается.
KD>Она сложна — да, это правда, поэтому она "умерла" для мелких проектов.

Примеры — в студию... (а то все мы может словами кидаться) У меня лично опыт совсем другой, я конечно не претендую на роль крутого ИТ менеджера, но сколько я не был в больших компаниях и сколько не общался с местными айтишниками то ИМНО 80% — это старый дорбый клиент сервер, 5% — экзотики всякой (включая и корбу) и 15% всяких модных штучек типа серверов приложений.

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

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

glh>Многие неофиты не знают элементарных вещей!

Ну да, конечно, опять все дураки а вы мнее всех...

glh>Проблемы использования и не использования чего-либо лежат совсем не в области программирования и проектирования и не имеют ничего общего с мощью или недостатками отдельных продуктов.

А кто говорил про недостатки Корбы, я просто утверждаю что она — умерла как технология и все. Это не значит что она была плоха.


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

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

KD>Кстати, Enterprise Java Beans (EJB) используют CORBA как бекэнд.

Ну вот чего кидаться словами если вас так легко на них поймать?

Какие сервера конкретно используют корбу как бэкенд (кроме Борландовского)?
И ссылочки конечно где это написано...


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

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

glh>Ну Вы наверное просто в том числе и на С# пишете, потому так и говорите — своя рубашка ближе к телу.

glh>Я, напротив, примерно уже с год как наблюдаю некоторое отврезвление.
glh>Зарплаты на NET просели, проекты в основной массе однотипные.

На job.ru сходите и сравните количество предложений работы на C# и Delphi, все вопросы отпадут


glh>Плюс, не забывайте о факторе массовости и/или моды.
glh>Там где массовость — там низкая квалификация, студенты и прочие "индусы".

И что? В джаве тоже массовость... Да и вообще миф о тупизне индусов — сильно преувеличен. Не стоит покупаться на массовое мнение...

V>>ну дак научите как сделать лучше? Раскажите какой брокер лучше использовать в коммерческой системе которая пересылает 1000 сообщений в минуту (хотя бы), как на C# работать с ним и т.д.

glh>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP.
glh>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.

glh>Естественно возникают трудности при работе с технологией, которые вынужденны решать разработчики.
glh>Либо сами, либо с помошью третьих вендоров. В частности у Borland было решение CORBA для NET, Ethera кажеться.

glh>Может быть он его уже интегрировали в VisiBroker — "Fully compliant with the CORBA 2.6 specification and beyond, VisiBroker supports development in Java, C++ and .NET languages, including Microsoft C++ and C#".

glh>PS. У нас в организации есть проекты и на NET(Сs) и на Java и на Win32(CB&Delphi).

Ну т.е. научить не можете? Дак тогда сидите и не учите других стоит им писать свой велосидеп или нет.


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

Давайте попробуем свести все?

Итак на суд общественности предлагается 2 варианта технического решения.

Вариант первый (для натоящих крутых программистов)
1. Команда прграммистов из города Кременчуг которая раньше разрабатывала на Deplhi, берет где то сервер приложений (я согласен, что Борланд так себе серверок, надо брать круче, они и стоят под $50 000, есть где развернуться настоящему программисту).
2. Они изучают J2EE (им же надо будет свою логику закинуть в этот сервер)
3. Они изучают CORBA и понимают как из нее соединиться с J2EE сервером (по ходу дела еще покупают Борландовский визиброкер для этого, который тоже несколько штук баксов стоит).
4. И потом если это все-таки смогут соединиться с этим сервером и пройти все технические сложности они смогут начать разрабатывать свою систему на java.

Мы не будем сюда добавлять что так как у них коммерческая система, то они должны ее разварачивать у заказчика, т.е. им надо будет еще на заказчика лицензии на весь этот софт покупать, конфигурить его и т.д. Это же фигня, для настоящих мужчин.


Вариант второй (изобретение велосипеда).
1. Они дают задание одному программисту прояитать книжку из серии "Java за 21 день", потом пару статей как надо из джавы работать с неблокирующимися сокетами и он за месяц — полтора пишет програмку на Deplhi, которая из некоторого описания ремотного интерфейса генерит серверный и клиентские стабы на нужном языке программирования, которые по TCP/IP будут байтики гонять по некоторому своему протоколу.
2. Садятся и пишут свой серверок на серверном стабе.


Ну и теперь если выключить "пальцы" доказывая друг другу какие мы тут крутые и включить здравый смыл, ответьте на вопрос какой путь для них правильный?


P.S. Я даже не хочу комментировать весь тот бред что Борландовский офис в России не занимался поддержкой их сервера приложений и то, что JBoss лучше BEA и Oracle.


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

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

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

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

Ну это достаточно просто решается и сейчас на Delphi, если использовать совмесно RemObject и DevExpress Quantum Grid.

У этого грида есть так называемый provider mode, когда он подключается не к обычным датасетам в Delphi,
а к любым произвольным пользовательским данным, через класс-адаптер (кстати, продукты devExpress определённо написаны под влиянием java)

То есть, это получается этакий MVC.
А класс TROArray в RemObject содержит методы для обращения к любому полю в струкртуре
по имени или индексу, (эти методы используются RemObject'ом для сериализации\десереализации, и используют внутри RTTI
— куций аналог java reflection).

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

То есть, все как написал ниже Blazkowicz.

Можено пойти еще дальше — для Quantum Grid написать свой view (наследник для TCustomTableView),
которое содержит в себе этот адаптер.
Тогда в design-time настраиваем столбцы грида и маппинг полей на структуры, в коде присваеваем ссылку на массив,
и можно работать с данными.

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


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

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

glh>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP.
glh>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.
Верно, но они уже реабилитировались в этом отношении — .NET Remoting.

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

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

B>> В Delphi нет рефликсии? Не верю.
6>Ну если только так WriteProcessMemory Function для не .net
Ну это вы совсе Delphi опускаете , зачем такие ужасы как WriteProcessMemory , все там есть.

Описание форм Delphi хранит в ресурсах, значит должна быть возможность установить значение свойства по имени,
и создать класс по назанию типа. Да и дизайнер форм без рефлексии никак не сделать.

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

Сорри за явный оффтопик в форуме java.

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

V>Давайте попробуем свести все?

V>Итак на суд общественности предлагается 2 варианта технического решения.

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

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

Но ведь данная ветка получилась такой не потому что надо решить задачу "вообще".
Вообще она решается элементарнейшим образом — транспорт на сокетах со своим прикладным протоколом, бинарным(BER, ASN, custom) или текстовым(XML или JSON), или сервлеты в контейнере и гонять тотже протокол по HTTP.

И где на чем там клиент и сервер становится глубоко фиолетово.

В определенный момент времени зашла речь о стандартизированных решениях не привязанных ни к платформе ни к языку. Вот тут-то и появилась и CORBA.

Если можно переписать все это одно.
Не многие могут это себе позволить.

Есть такие штуки как совместимость, преемственность.
Одно дело внутренний(например) продукт и совсем другое разработка, на которую потрачемы миллионы.
Инсталляции у тысяч клиентов и тд и тп

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

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

glh>>Ну вот посмотрите, вендор сознательно исключает поддержку конкурента. Ведь для MS родные (d)COM(+) и SOAP.
glh>>Потому как у CORBA есть "фатальный недостаток — его придумали не они" и XML-RPC кстати тоже.
R>Верно, но они уже реабилитировались в этом отношении — .NET Remoting.

да забыл просто написать

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

glh>В определенный момент времени зашла речь о стандартизированных решениях не привязанных ни к платформе ни к языку. Вот тут-то и появилась и CORBA.

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


Но уж если мы переключились на эту тему, то почему тогда не SOA?



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

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

V>Но уж если мы переключились на эту тему, то почему тогда не SOA?

тем, что это не стандарт, а некие общие характеристики некоторого подхода, подкреплённые безудержным маркетинговым buzz
в конкретных приложениях на конкретных реализациях SOA видно, что за всем стоят обычные технологии, которые, вдобавок, применяются неправильно

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

V>Итак на суд общественности предлагается 2 варианта технического решения.

это два полярных варианта, а истина где-то посередине.

V>Ну и теперь если выключить "пальцы" доказывая друг другу какие мы тут крутые и включить здравый смыл, ответьте на вопрос какой путь для них правильный?

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

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

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

V>P.S. Я даже не хочу комментировать весь тот бред что Борландовский офис в России не занимался поддержкой их сервера приложений и то, что JBoss лучше BEA и Oracle.

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

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

C0s>а на чём основывается твоё резкое высказывание?
C0s>я, например, какой-то период был в обойме людей, тесно с ними сотрудничавших. сидел там в 15 метрах, можно сказать, и кое что про их кухню того времени представляю. нельзя сказать, что суппорта вообще не было, но техническими вещами они не занимались.

Да просто я знаком с человеком кто это support осуществлял, т.е. решал реальные архитектурные и технические задачи.


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

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

C0s>это два полярных варианта, а истина где-то посередине.

Но людям то сейчас решение надо, сегодня... Вот они и пришли умных советов послушать. Истина — она понятно всегда посередине, только им все равно надо из Delphi соединяться к java

C0s>с моей точки зрения, она заключается в движении в сторону стандартизованных (де-юре или де-факто) средств с преимущественно открытым кодом, что позволит сократить велосипедостроение и добавить смысла. возможное наличие инвестирования в платные вещи просто как плюс, которым можно при удаче с умом воспользоваться

Да кто же с этим спорит что стандартизированные средства лучше? Только вот где их взять в этой конкретной задаче?

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


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

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

V>>Но уж если мы переключились на эту тему, то почему тогда не SOA?

C0s>тем, что это не стандарт, а некие общие характеристики некоторого подхода, подкреплённые безудержным маркетинговым buzz
C0s>в конкретных приложениях на конкретных реализациях SOA видно, что за всем стоят обычные технологии, которые, вдобавок, применяются неправильно


Ну я наверное соглашусь что четкого стандарта на всю SOA нет, но ведь SOAP, WSDL, UDDI — это стандарты. WS-security и WS-Transactions насколько я помню уже тоже стандартизированы. Что разве этих стандартов не хватит для начала?


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

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

V>Ну я наверное соглашусь что четкого стандарта на всю SOA нет, но ведь SOAP, WSDL, UDDI — это стандарты. WS-security и WS-Transactions насколько я помню уже тоже стандартизированы. Что разве этих стандартов не хватит для начала?

для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами
т.е. проблема не в аббревиатуре, проблема в её каком-то особом толковании и мнении о ней как об очередной серебряной пуле

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

V>Да просто я знаком с человеком кто это support осуществлял, т.е. решал реальные архитектурные и технические задачи.

ну, напиши плиз в личку, как его зовут, мне же интересно

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

Можно смотреть на Axis. С его помощью довольно легко делаются SOAP сервисы на Яве. А по соответствующим WSDL-кам Дельфи сгенерирует стабы. В результате есть канал общения. Клиента, ИМХО, можно разом не перекраивать — временно оставить клиентские датасеты и обновлять их сгенерёнными по WSDL-кам классами. А потом по-маленьку перекидывать контролы с датасетов на что-то более удобное и прямое.

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

C0s>для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами

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

C0s>т.е. проблема не в аббревиатуре, проблема в её каком-то особом толковании и мнении о ней как об очередной серебряной пуле

Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.


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

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

C0s>ну, напиши плиз в личку, как его зовут, мне же интересно

Ответил на емайл что у вас в профайле

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

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

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

кроме веб-сервисов ещё есть асинхронный мессаджинг. соответственно, если конкретный производитель message service предоставляет API на нескольких языках, то возникает какая-то независимость от языка разработки (в пределах поддерживаемых), но добавляется зависимость от производителя.

усреднённые подходы тоже годятся. например, в случае java JMS как стандартный способ может использоваться для взаимодействия всех компонентов, написанных на Java. для всех остальных же пишутся или конфигурируются (если платформа позволяет) web services, адаптирующие посылку-приём сообщений

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

V>Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.

корба-то помощнее будет, собственно о чём и речь — чистая корба сама по себе сложна, но аппсервер, сделанный по стандарту должен её поддерживать в том или ином виде в качестве транспорта ejb (с предоставлением соотв. обязательных сервисов). соответственно, имея в арсенале ejb(slsb)/corba/jms/web/web services, можно добиться многого, если не всего. и для большинства случаев это будет более оправдано в экономическом смысле, чем писание доморощенных протоколов, равно как и прикручивание standalone-реализаций web services.

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

C0s>корба-то помощнее будет, собственно о чём и речь — чистая корба сама по себе сложна, но аппсервер, сделанный по стандарту должен её поддерживать в том или ином виде в качестве транспорта ejb (с предоставлением соотв. обязательных сервисов). соответственно, имея в арсенале ejb(slsb)/corba/jms/web/web services, можно добиться многого, если не всего. и для большинства случаев это будет более оправдано в экономическом смысле, чем писание доморощенных протоколов, равно как и прикручивание standalone-реализаций web services.

Да, с этим я полностью согласен.

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

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

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

C0s>>для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами

V>то, что SOA это архитектурный подход — это понятно, только кроме веб сервисов на данный момент никто не сможет обеспечить этот подход (про корбу только давайте сначала не начинать ) когда требуется независимость от языка разработки.
Вы под веб-сервисами имеете в виду этот кошмар в виде SOAP/WSDL/UDDI? Да ну. Между прочим, веб сервисы работали за 10 лет до SOAP и прекрасно без него обходились.
Типичный пример веб-сервиса — процессинг платежей по кредиткам. Отродясь он работал в виде HTTP POST, и имел все преимущества протокола, независящего от языка, проходящего скрозь прокси и все остальные бла-бла-бла.
При этом реально написать клиента к этому сервису до сих пор проще, чем заиспользовать мега-SOAP.

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

Так что я совершенно согласен с SOA, но к SOAP никакой теплоты не испытываю.

V>Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.
Ну, я бы всё же разделил протокол и архитектуру. Альтернативных соапу протоколов — вагон и маленькая тележка, только они меньше раскручены. Технически он из себя ничего особенного не представляет.

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

S>Вы под веб-сервисами имеете в виду этот кошмар в виде SOAP/WSDL/UDDI? Да ну. Между прочим, веб сервисы работали за 10 лет до SOAP и прекрасно без него обходились.
S>Типичный пример веб-сервиса — процессинг платежей по кредиткам. Отродясь он работал в виде HTTP POST, и имел все преимущества протокола, независящего от языка, проходящего скрозь прокси и все остальные бла-бла-бла.
S>При этом реально написать клиента к этому сервису до сих пор проще, чем заиспользовать мега-SOAP.


Дело не в SOAP, а в том что есть WSDL который описывает интерфейс веб сервиса (чего совсем нет в вашем подходе дергания сервера по HTTP) и есть еще UDDI, который находит нужные сервисы. Без этого SOA жить не будет.


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

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

V>Дело не в SOAP, а в том что есть WSDL который описывает интерфейс веб сервиса (чего совсем нет в вашем подходе дергания сервера по HTTP) и есть еще UDDI, который находит нужные сервисы. Без этого SOA жить не будет.
SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.

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

S>SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.

Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут. И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса. Одно это сводит на нет преимущества простого HTTP запроса (если они и были вообще).

А какие кстати правила которые плохо переносятся?


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

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

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

S>>SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.

V>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут.
1. Это используется в жизни?
2. Вы уверены, что это является неотъемлемой частью идеологии SOA?

V> И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса.
Они описывают его из рук вон плохо. В том смысле, что предназначены для генераторов клиентских stub'ов, что якобы облегчает написание клиентского кода.
В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода.
V>Одно это сводит на нет преимущества простого HTTP запроса (если они и были вообще).
Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++.

V>А какие кстати правила которые плохо переносятся?
Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi.
Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность.
V>Вячеслав Педак

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

S>Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi.
S>Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность.



А потом технология, язык и/или платформа X объявляется умирающей и/или неправильной, потому как на поддерживает частную фичу от Y.
Y объявляется следующей серебрянной пулей, используя которую можно лежать под пальмой и ничего не делать.
До следующего раза, когда обнаружится новая фенечка в виде Z.

PS Все намеки и совпадения надуманны.

PS 2 Искали несколько месяцев назад программиста на COBOL. Сами в г.Москва.
Ближайший "москвич" нашелся в Бельгии, приехать за 6000 евро/месяц отказался.

PS 3

Автор: VladD2
Дата: 13.10.04

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


V>>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут.
S>1. Это используется в жизни?

да

S>2. Вы уверены, что это является неотъемлемой частью идеологии SOA?

да

Меркури недавно купила Sysinet (произволителя этих самых реестров для SOA) за $105 миллионов, а потом HP купил и ее за $4.5 миллиарда
Вот такие вот цифирки для раздумья

V>> И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса.
S>Они описывают его из рук вон плохо. В том смысле, что предназначены для генераторов клиентских stub'ов, что якобы облегчает написание клиентского кода.

А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох? А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?

S>В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода.

Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. И опять же если есть лучше протоколы — поделитесь...
Я не вредничаю, я правда хочу понять, может я пропустил чего.


S>Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++.

Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны. Я работаю в конкретной области бизнес приложений, где они наиболее востребованы.


V>>А какие кстати правила которые плохо переносятся?
S>Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi.
S>Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность.


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


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

Здравствуйте, vpedak, Вы писали:
S>>1. Это используется в жизни?
V>да
круто.
S>>2. Вы уверены, что это является неотъемлемой частью идеологии SOA?
V>да
А можно ссылочку, где про это почитать? А то я, судя по всему, слишком расслабленно трактую термин SOA.
V>Меркури недавно купила Sysinet (произволителя этих самых реестров для SOA) за $105 миллионов, а потом HP купил и ее за $4.5 миллиарда
V>Вот такие вот цифирки для раздумья
Я слишком туп, чтоб думать над голыми цифирками. Вот ничем не хуже цифирка.
Поясни, чем именно занимается эта Sysinet. А то я по немецки не слишком бегло читаю.

V>А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох?
Да сколько угодно. Вот например, один из протоколов Authorize.Net.
Обрати внимание на невыразимую в WSDL информацию: как настроить, что передавать.
Написать клиента к Authorize.net очень легко, несмотря на отсуствие генератора стабов.
V>А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?
Надо описывать семантику вызовов. А про это WSDL тебе ничего не скажет.

V>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple.
http://www.w3.org/TR/soap12-part1/ — 55 страниц, не считая ссылок на внешние документы. Я дал пример, где протокол описан вместе с конкретным API, и то он занимает меньше места.
V>И опять же если есть лучше протоколы — поделитесь...
Лучшие — есть.
Стандартных — нету.
Значительно лучшим протоколом является XML-RPC.
Лучшим протоколом является REST.
Лучшим протоколом является JsHttpRequest — его клиентом может выступать даже браузер.
V>Я не вредничаю, я правда хочу понять, может я пропустил чего.


S>>Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++.
V>Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны.
Если вас интересует только два языка в плане написания клиентов к вашему сервису, то вместо отдачи WSDL и надежды на то, что у разработчика клиента под рукой окажется нужный генератор, проще сделать 2 (две) клиентские библиотеки на этих языках. SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено.
V>Я работаю в конкретной области бизнес приложений, где они наиболее востребованы.
Я понимаю — потому мне и интересно общаться. Мы работаем в совсем другой области, и интересно сравнить опыт применения.


V>Я не совсем понял что такое проблемы с версионированием SOAP сервисов, насколько я помню SOAP вообще редко меняется.
Я не про сам SOAP, я про API на основе SOAP. То, что написано в WSDL, не вырубишь топором. Фундаментальная проблема — в жуткой затипизированности SOAP.
API обычно существует не сам по себе; он предоставляет доступ к некоторой модели предметной области. Эта модель всё время меняется. И API должен, с одной стороны, давать доступ к этим новым явлениям, а с другой стороны — обеспечивать обратную совместимость. Банальный Name/Value POST (как в примере от Authorize.net), к примеру, совершенно к этому нечувствителен. Сервер, увидев, что какие-то из новых параметров не переданы, поймет, что клиент вызывает старую версию протокола, и вернет соответствующие данные. В XML-RPC клиент точно указывает, какая часть структуры ему интересна, и сервер никогда не вернет ему лишнего. И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.


V>А про то, что народ непрозрачно сериализует — дак ножиком можно и хлеб резать и людей убивать — думать оно всегда полезно. Технология не всегда может влиять на неправильное ее использование.
Еще как может. Если единственный способ обеспечить две версии API в одном ендпоинте сводится к отказу от типизации — все так и будут делать.

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

V>>>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут.
S>>1. Это используется в жизни?
V>да
Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus).

V>А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох? А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?
Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно.

S>>В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода.
V>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. И опять же если есть лучше протоколы — поделитесь...
SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access.

Я лично использую SOAP как последнее средство для интеграции или когда он диктуется внешними условиями. Вообще, по ощущения SOAP сейчас повторяет путь CORBA — та же куча стандартов, которые целиком никто пока не реализует, та же тяжеловесность и та же "enterprise"-овость.

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

S>Лучшие — есть.
S>Стандартных — нету.
Вот в этом-то и большой плюс WDSL. Как не крути, а это стандарт, который поддерживают все кому не лень и по многу раз.

S> И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.
У меня пока стойкое ощущение, что это правильно.

S>Еще как может. Если единственный способ обеспечить две версии API в одном ендпоинте сводится к отказу от типизации — все так и будут делать.
А в чем смысл иметь две версии протокола на одном эндпоинте?

Здравствуйте, IB, Вы писали:
S>>Лучшие — есть.
S>>Стандартных — нету.
IB>Вот в этом-то и большой плюс WDSL. Как не крути, а это стандарт, который поддерживают все кому не лень и по многу раз.
Угу. Только вот этих "всех" мало, и все поддерживают его по-разному.

IB>А в чем смысл иметь две версии протокола на одном эндпоинте?
В том, что тебе не нужно тащить столько ендпоинтов, сколько у тебя было версий протокола. Из шарпа это еще и не вполне тривиально сделать — для корректной сериализации нужно тащить с собой N комплектов классов передаваемых данных.
Трудно написать клиента, поддерживающего разные версии сервера — он должен стучаться в кучу потенциальных ендпоинтов, вместо того, чтобы один раз подключиться и договориться. При апгрейде сервера клиенту нужно перенастроить подключение руками.

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

C>Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus).

С этиим согласен, что это все очередная разводка на деньги для маркетологов Но слишком уж много денег в это вложено, так что может и доведут до нормального состояния

C>Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно.

Я тоже за, только ИМНО Corba — умерла уже (выше все это обсуждали)

C>SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access.

Был он simple — http://en.wikipedia.org/wiki/SOAP


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

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

S>А можно ссылочку, где про это почитать? А то я, судя по всему, слишком расслабленно трактую термин SOA.

http://en.wikipedia.org/wiki/Service-oriented_architecture

S>Поясни, чем именно занимается эта Sysinet.

Здесь все подробно описано — https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-130-27^1461_4000_100__

S>Обрати внимание на невыразимую в WSDL информацию: как настроить, что передавать.

WSDL содержит информацию и о том куда передавать и как.

V>>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple.
S> http://www.w3.org/TR/soap12-part1/ — 55 страниц, не считая ссылок на внешние документы. Я дал пример, где протокол описан вместе с конкретным API, и то он занимает меньше места.

Нельзя сравнивать general purpose коммуникационный протокол, который позволяет описывать и передавать любые данные и специфичный протокол.
Проблема то в том, что если везде пихать специфичные протоколы, то потом поддерживать это все будет очень тяжело


V>>И опять же если есть лучше протоколы — поделитесь...
S>Лучшие — есть.
S>Стандартных — нету.

Ну вот это видимо и самая большая проблема.

V>>Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны.
S>Если вас интересует только два языка в плане написания клиентов к вашему сервису, то вместо отдачи WSDL и надежды на то, что у разработчика клиента под рукой окажется нужный генератор, проще сделать 2 (две) клиентские библиотеки на этих языках.

Мы так и сделали

S>SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено.

Но маркетинг требует поддержки web services как стандартного межплатформенного API

V>>Я не совсем понял что такое проблемы с версионированием SOAP сервисов, насколько я помню SOAP вообще редко меняется.
S>Я не про сам SOAP, я про API на основе SOAP. То, что написано в WSDL, не вырубишь топором. Фундаментальная проблема — в жуткой затипизированности SOAP.
S>API обычно существует не сам по себе; он предоставляет доступ к некоторой модели предметной области. Эта модель всё время меняется. И API должен, с одной стороны, давать доступ к этим новым явлениям, а с другой стороны — обеспечивать обратную совместимость. Банальный Name/Value POST (как в примере от Authorize.net), к примеру, совершенно к этому нечувствителен. Сервер, увидев, что какие-то из новых параметров не переданы, поймет, что клиент вызывает старую версию протокола, и вернет соответствующие данные. В XML-RPC клиент точно указывает, какая часть структуры ему интересна, и сервер никогда не вернет ему лишнего. И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.

Но это же тоже несложно решить архитектурно. Кто мешает на том же SOPA передавать name value значения. ИМНО от типизированности больше пользы чем вреда. Зато гадость лишнюю не засунут в данные.

Да и создание нового end point это тоже не плохой вариант, то что будет 2 end pointa поддерживающие разные версии — это же хорошо даже.


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

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

V>http://en.wikipedia.org/wiki/Service-oriented_architecture
Цитируем:

Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST.

V>Здесь все подробно описано — https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-130-27^1461_4000_100__
Ок, понятно.

S>>Обрати внимание на невыразимую в WSDL информацию: как настроить, что передавать.
V>WSDL содержит информацию и о том куда передавать и как.
Нет. В WSDL нигде, к примеру, не будет сказано в каком порядке вызывать методы, или что они делают.


V>Нельзя сравнивать general purpose коммуникационный протокол, который позволяет описывать и передавать любые данные и специфичный протокол.
Конечно можно. Мы говорим о том, что вменяемый протокол описывается гораздо короче.
V>Проблема то в том, что если везде пихать специфичные протоколы, то потом поддерживать это все будет очень тяжело
На практике, я думаю, потребителей Authorize.net на пару порядков больше, чем у веб сервисов. И с поддержкой у них не слишком плохо.

V>Ну вот это видимо и самая большая проблема.
Ага.

V>Мы так и сделали
Тогда какая вам разница — есть WSDL или его нету?

S>>SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено.
V>Но маркетинг требует поддержки web services как стандартного межплатформенного API
Вот! И мы наступили в те же грабли. Маркетинг, голимый маркетинг.

V>Но это же тоже несложно решить архитектурно. Кто мешает на том же SOPA передавать name value значения.
)
Это прямо по анекдоту про попытку заинтересовать бизнесом.
Ну и надо было столько трахаться, WSDL, импорт, стабы, неймспейсы, кастом хидеры, эмуляция транзакций — и всё ради чего? Чтобы name/value передавать? Чудовищно!

V>ИМНО от типизированности больше пользы чем вреда. Зато гадость лишнюю не засунут в данные.
ХаХа.
V>Да и создание нового end point это тоже не плохой вариант, то что будет 2 end pointa поддерживающие разные версии — это же хорошо даже.
Эта иллюзия продолжается у всех по-разному. У меня она начала проходить к третьей версии нашего протокола, а выход четвертой ее окончательно похоронил.

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

C>>Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus).
V>С этиим согласен, что это все очередная разводка на деньги для маркетологов Но слишком уж много денег в это вложено, так что может и доведут до нормального состояния
Сам-то в это веришь? Текущий SOAP вообще один-в-один повторяет CORBA.

C>>Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно.
V>Я тоже за, только ИМНО Corba — умерла уже (выше все это обсуждали)
В CORBA было слишком много неправильных решений, так что умерла она вполне заслужено.

Кстати, мне сейчас больше всего нравятся тупые легковесные протоколы типа Hessian (используем его для связи программы на С++ на встроеном устройстве и сервера на Java) или XML-RPC (используем для клиентского API).

C>>SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access.
V>Был он simple — http://en.wikipedia.org/wiki/SOAP
Так я же написал "сейчас"

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

S>Цитируем:
S>

Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST.

Дак кто против то? Я говорил только о том, что на мой взгляд сейчас SOA наиболее реально реализовать именно на веб сервисах, так как они более всего распространены, стандартизованы и все.

S>Нет. В WSDL нигде, к примеру, не будет сказано в каком порядке вызывать методы, или что они делают.

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

S>Тогда какая вам разница — есть WSDL или его нету?

Ну мы же не о нашем конкретном случае говорим, а вообще... Что нам ждать в будующем

S>Вот! И мы наступили в те же грабли. Маркетинг, голимый маркетинг.

Это да, только славо богу маркетинг не может диктовать всего, поэтому мы все равно будем поддерживать наше custom решение и веб сервисы пойдут в добавку к этому

S>Ну и надо было столько трахаться, WSDL, импорт, стабы, неймспейсы, кастом хидеры, эмуляция транзакций — и всё ради чего? Чтобы name/value передавать? Чудовищно!

Я же не говорю что так надо делать обызательно, но так ничто не межает сделать технически. Выбор — это всегда хорошо.


S>Эта иллюзия продолжается у всех по-разному. У меня она начала проходить к третьей версии нашего протокола, а выход четвертой ее окончательно похоронил.

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

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

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

C>Сам-то в это веришь? Текущий SOAP вообще один-в-один повторяет CORBA.

Я уже боюсь даже во что-то верить, все так быстро меняется... Лучше я подожду, пусть другие "копья ломают"

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