COM, SOAP и пр. в реальной жизни. Обмен опытом.

[RXL]

Господа, а давайте лучше холивар переведем на сравнение DCOM и SOAP+WSDL. Интересно, для общего развития, услышать мнение уже применявших.

С DCOM я уже поработал - через COM-stub: ничем от COM не отличается, кроме еще большей тормознутости. В VB использовать просто, в компилируемых языках - менее удобно. С генерацией вропера для BCB6 чуть не повесился - пришлось через Delphi7 делать (баги BCB6), а потом еще свой вропер поверх дописывать (ужасно неудобно было пользоваться).

От SOAP-WSDL не жду большей скорости, т.к. они базируются на XML, но зато это открытые стандарты.

Еще один интересный момент: с сохранением состояния или без (как пропагандирует SOA).

[lapulya]

RXL, ИМХО это отдельная тема

[RXL]

Вот теперь это отдельная тема. Прошу высказываться

Думаю вот, будет ли лучше, если существующее GUI ПО, работающее с БД напрямую, разделить на серверную и клиентскую часть. Хочу оценить возможные и гарантированные плюсы и минусы.

[lapulya]

ЭЭЭЭ ну чего сказать... DCOM отстой WSDL рулит)))) кто против?

[RXL]

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

Потратил вечер на самообразование: почитал о куче всяких RPC и форматов обмена, которые наизобретали за последнее десятилетие. Мне больше всего понравился формат JSON и протокол JSON-RPC (через HTTP). Собственно, они для меня новинкой не стали - просто ничего красивее и проще не нашел. Единственное, где он проигрывает - при передаче больших бинарных данных (например, картинок).

[lapulya]

а в чем прелесть по сравнению с WSDL? мы с клиента асинхронно (в случае тонкого клиента) запрашиваем вебсервис. Передаем в запросе в заголовке параметры (типа как при методе GET), веб сервис разбирает параметры формирует xml и отправляет его клиенту. Клиент получает xml и потрошит самостоятельно или при помощи заранее заготовленного xslt шаблончика.

могу дать пару ссылок как сие в динамике . Против JSON ничего не имею, но его преимущество мне не очевидно.

если пишешь под веб очень рекомендую jquery, там и json и wsdl... чумовая библиотека.

[RXL]

lapulya, не думаю, что можно сравнивать формат данных (JSON) и протокол вызовов (JSON-RPC) с форматом описания сервисов (WSDL). Каким протоколом вы пользуетесь?

JSON: http://www.ietf.org/rfc/rfc4627.txt
Если сравнивать JSON с XML-базированными форматами, то он выигрывает простотой, компактностью и тем, что работать с ним на клиенте проще, чем с DOM. А еще его фишка в том, что в JavaScript он преобразуется в структуру одним оператором eval (секюрность в JavaScript решаемая: RFC 4627, параграф 6). Кодирование в JSON тоже очень простое. Имеется поддержка для кучи языков.
Типизация слабая: одномерные массивы, объекты (ассоциативные массивы) и скаляры (строки, числа, булевы значения и null).

JSON-RPC: http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal (2.0)
JSON-RPC выглядит как набор сообщений формата JSON и аналогичный набор ответов. Крайне простой.
В чем-то напоминает принцип XMSS (Jabber). Только в XMSS - потоковый XML, а тут - потоковый JSON.

На базе JSON-RPC даже сделали гибрид с SOAP - SOAPjr: http://soapjr.org/specs.html
Разработчики пошли тем же путем: транслировали XML в JSON.

У меня задумка не про web, но хотелось бы иметь совместимость. Идея - развязать клиентские приложения и БД. Правда, все равно остается узкое место - отчеты в Crystal Reports - им нужен коннект к базе. Вот если бы можно было слить данные в какую-нибудь структурку типа XML, а потом CR оттуда их взял бы - было бы здорово.

[RXL]

https://club.shelek.ru/viewart.php?id=323
Накатал статью в поддержку JSON

[lapulya]

RXL, нуууу не так все плохо... если уж сравнивать xml и json, то честно, тем более в статье. Можно конечно передать данные xml так, как ты написал (но кто ж так делает, пример смотри ниже), но можно и гораздо короче (да, длиннее, чем json, но далеко не на столько, насколько показано в статье) и информативнее, и кстати, легче читается, чем json данные (не надо гадать, что это за данные, т.е. record значит record, а не какие-то там данные).

<peoples>
  <record id="1" surname="Иванов" firstname="Иван" patronymic="Иванович" />
  <record id="2" surname="Петров" firstname="Петр" patronymic="Петрович" />
</peoples>

Далее... DTD просто так выкинули, списав на ограничение... хммм ну это резковато, это как раз мега вещь, которая проверяет и отсекает лишний поток данных! Представьте вы делаете приложение v1, далее идет модернизация, если вы хотите/можете обрабатывать старый формат ок (опускаю, что его можно проверить), а вот если нет, то ваше приложение и не рыщет в данных, DTD просто признает данные некорректными и "досвидос"! Это как в коме QueryInterface, как же ее просто так в утиль списали...

Далее... атрибуты приравняли к борьбе за компактность, ну как же так... это же типичнейший пример классификации и структуризации объектов! Атрибут это именно атрибут! Он не имеет смысла/значения в отрыве от своей сущности (это как раз в укор данным в статье peoples, records). Это все равно как в каждом C++ классе каждый мембер делать новым классом (ну или в БД, каждое поле таблицы выносить в отдельную таблицу). Так что атрибуты они не для компактности, а для структуры данных.

Далее... eval... ну на мой взгляд не самый лучший вариант, особенно при приходе "битых" (портят не столько данные, сколько структуру, например пришло 'id' => 1, но без запятой в конце) данных (не отстой, а просто не лучший вариант ), если же "битые данные" придут в виде XML, то DTD просто пошлет их далеко, а вот eval... Кстати, а что если JS на клиенте отключен? А с проверками xslt справляется на раз и без строчки кода и куда как проще (ИМХО, потому как сам xslt и xPath проще js). Кто не верит смотрим сюда -> https://www.wow-europe.com/ru/index.xml, а так же на все остальное от близзард (обновление контента производится очень часто и очень сильно, а иногда и структуры данных). Причем xslt это лишь один из вариантов, не нравится, вот вам в руки js.

Структура данных, это структура данных т.е.
<data>
    <object1>
        <subobject/>
        <object2>
            < subobject/>
        </object2>
    </object1>
</data>
Таким образом subobject это данные определяющие (как правило) один и тот же класс объектов. Это ясно сразу как при просмотре "глазом", так и парсером/шаблоном. Соответственно и обрабатываться он может по всем вхождениям в xml документ (причем "бесплатно" для программиста) в отдельном шаблоне/функции/т.д., тут как раз завязка именно на структуру данных (которую еще и DTD проверит если надо). А вот этой то структуры в JSON и нет (разбор пришедшего на клиент "мяса и винегрета" данных полностью лежит на js), лишь голые данные (а что это, знает лишь js и никто другой)

Более по статье ничего сказать не могу php не знаю.

Да, и не забываем, что на xml легко натравливается любой xslt шаблон (в любых количествах), а с данными json справится только js, это в дополнение ко всем недостаткам указанным в статье. Так что надо 2 раза подумать, чем пользоваться. А статью надо подкорректировать, иначе это просто дискредитация WSDL  .

ЗЫ
Полное ИМХО - никаких достоинств у JSON кроме компактности (и как не прискорбно это звучит - скорости, но скорость на теперешних машинах и относительно малых xml документах, до 10 МБ, будет на глаз почти незаметна) нет, зато минусов хоть отбавляй.

[lapulya]

RXL,

lapulya, .... Каким протоколом вы пользуетесь?

http, https

Если сравнивать JSON с XML-базированными форматами, то он выигрывает простотой, компактностью

Да, он немного (совсем немого) выигрывает в компактности, простотой не выигрывает из-за непрозрачности пришедших данных (что это за данные знает лишь js, а в xml чет ко все видно).

и тем, что работать с ним на клиенте проще, чем с DOM.

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

Более подробно в предыдущем сообщении (может я его не туда запостил, конечно...)

[RXL]

Вид для чтения:

Код:

<peoples>
  <record id="1" surname="Иванов" firstname="Иван" patronymic="Иванович" />
  <record id="2" surname="Петров" firstname="Петр" patronymic="Петрович" />
</peoples>
[
  {@id:1, @surname:"Иванов", @firstname:"Иван", @patronymic:"Иванович"},
  {@id:2, @surname:"Петров", @firstname:"Петр", @patronymic:"Петрович"}
]
[
  {id:1, surname:"Иванов", firstname:"Иван", patronymic:"Иванович"},
  {id:2, surname:"Петров", firstname:"Петр", patronymic:"Петрович"}
]

Вид для работы:

Код:

<peoples><record id="1" surname="Иванов" firstname="Иван" patronymic="Иванович" /><record id="2" surname="Петров" firstname="Петр" patronymic="Петрович" /></peoples>
[{@id:1,@surname:"Иванов",@firstname:"Иван",@patronymic:"Иванович"},{@id:2,@surname:"Петров",@firstname:"Петр",@patronymic:"Петрович"}]
[{id:1,surname:"Иванов",firstname:"Иван",patronymic:"Иванович"},{id:2,surname:"Петров",firstname:"Петр",patronymic:"Петрович"}]

Специально сделал два варианта JSON: как бы с эмуляцией атрибутов и без оного. Размеры видно сразу. Читаемость не страдает.

Честно говоря, не пойму, чего ты взъелся. Я же не предлагаю "списать" XML. Ясно в статье сказал: для ряда задач.

Насчет "кто так делает": может ты так не делаешь, а посмотри открытые форматы - сплошь и рядом. Убивает меня конструкция типа "<member><name>aaa</name><value>111</value></member>".
Вот пример из XML-RPC. Для большего интереса добавил туда третий член - структуру:

Код:

<struct>
   <member>
     <name>Что-то</name>
     <value><i4>1</i4></value>
   </member>
   <member>
     <name>Ещё что-то</name>
     <value><i4>2</i4></value>
   </member>
   <member>
     <name>Ещё что-то</name>
     <value>
       <struct>
         <name>Ещё что-то еще</name>
         <value><i4>2</i4></value>
      </struct>
     </value>
   </member>
</struct>

Я бы сделал так:

Код:

<struct>
   <i4 name="Что-то">1</i4>
   <i4 name="Ещё что-то">2</i4>
   <struct name="Ещё что-то">
         <i4 name="Ещё что-то еще">2</i4>
   </struct>
</struct>

или так

<struct>
   <i4 name="Что-то" value="1" />
   <i4 name="Ещё что-то" value="2" />
   <struct name="Ещё что-то">
         <i4 name="Ещё что-то еще" value="2" />
   </struct>
</struct>

Насчет eval: RFC ты явно не читал.

Кстати, а что если JS на клиенте отключен?

А если у него и электричества нет?

Не понял, при чем тут WSDL? То, что это XML формат? И как существование JSON дискредитирует WSDL?

Ты меня извини, но кажется, что ты порой сравниваешь несравнимые вещи. Например, припомню тебе WSDL Это не протокол RPC, а средство описания RPC-сервисов без привязки к определенному транспорту и протоколу (привязка осуществляется самим WSDL). В одном файле можно описать сервисы SOAP, DCOM, JSON-RPC, XML-RPC и все что угодно - что там еще напридумывали (лишь бы клиент это поддерживал).

[RXL]

RXL,

lapulya, .... Каким протоколом вы пользуетесь?

http, https

Эээ... Я имел в виду протокол запросов.

и тем, что работать с ним на клиенте проще, чем с DOM.

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

Более подробно в предыдущем сообщении (может я его не туда запостил, конечно...)

Проще. Во-первых, нет строгой модели и кучи переборов. Дерево объектов чистое, без лишних прослоек для поддержки DOM-отношений между узлами. Нет никаких Value.
Сравни выражения JS:

Код:

object.property

object.getElementsByTagName("property")[0].value

Даже если описать в DTD, что property в object модет быть только один, API от этого не меняется и приходится искать все "property" и выбирать первый. В объектах JS имя уникально.

[sss]

Использовал COM, DCOM....
1) для использования чужих серверов автоматизации (AutoCAD, Word, Excel ...). Может быть можно было через SOAP+WSDL ? Научите...
2) для создания фильтра в медиапотоках.  DirectShow ожидает поведения объекта COM класса, а не SOAP+WSDL...
3) для создания оснасток mmc
4) для редактирования собственных дескрипторов безопасности системным редактором...

и т.д. и т.п.

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

[lapulya]

sss, ну для начала никто не предлагал использовать WSDL, SOAP вместо COM, а потом:

1) для использования чужих серверов автоматизации (AutoCAD, Word, Excel ...). Может быть можно было через SOAP+WSDL ? Научите...

да запросто, пиши свой поставщик данных и будет тебе AutoCAD, а по поводу Word, Excel, тут уже все сделано за нас, майкрософт на данной стадии пока только обернул COM (и эти обертки аккурат xml пересылают, насколько мне известно), но погоди, пудет и полный праздник на нашей улице

2) для создания фильтра в медиапотоках.  DirectShow ожидает поведения объекта COM класса, а не SOAP+WSDL...

речь шла о DCOM, а не о COM

3) для создания оснасток mmc

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

4) для редактирования собственных дескрипторов безопасности системным редактором...

А что это? Хотя какая разница, что это, при любых раскладах я не вижу препятствий перевести на WSDL

Если все не упирается в:
1. ширину канала передачи
2. скорость работы (кстати возможно по этому параметру WSDL, JSON тут не прокатят, хотя если данные паковать...)
3. объем отжираемых ресурсов
то нет никаких проблем и препятствий перевести абсолютно любой поставщик данных на WSDL, JSON и т.д.

RXL, отвечу позже.

[sss]

да запросто, пиши свой поставщик данных и будет тебе AutoCAD, а по поводу Word, Excel, тут уже все сделано за нас, майкрософт на данной стадии пока только обернул COM (и эти обертки аккурат xml пересылают, насколько мне известно), но погоди, пудет и полный праздник на нашей улице

Какой поставщик данных? Я вызываю методы объектов

речь шла о DCOM, а не о COM

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

Блин, для программиста нет особой разницы - DCOM или COM.

Показатель успешности в таких вещах один - объем отжираемых бабок. И всё...

[lapulya]

RXL,

Честно говоря, не пойму, чего ты взъелся. Я же не предлагаю "списать" XML. Ясно в статье сказал: для ряда задач.

не, не я только статью обсуждаю, не более того, просто в статье как-то "опущен" WSDL, хочу справедливости  

Вид для чтения:
...
Вид для работы:
...

еще как страдает читаемость, я ж говорю в JSON совершенно не понятно что это за данные (данные какого объекта, ну например, приведу стремную ситуацию, есть два разных объекта с одинаковым набором атрибутов, что будет видно при просмотре данных JSON? Да, эти объекты могут существовать на одном уровне иерархии), особенно при увеличении вложенности. Про размеры, я ж подтвердил, что XML длиннее, но далеко не в 2 раза, как указано в статье а процентов на 10, я как раз об этом.

Ни разу в прикладном ПО (современном, а не на заре эпохи ) не видел такого

Код:

<struct>
   <member>
     <name>Что-то</name>
     <value><i4>1</i4></value>
   </member>
   <member>
     <name>Ещё что-то</name>
     <value><i4>2</i4></value>
   </member>
   <member>
     <name>Ещё что-то</name>
     <value>
       <struct>
         <name>Ещё что-то еще</name>
         <value><i4>2</i4></value>
      </struct>
     </value>
   </member>
</struct>

кроме как возможно в web (если смотреть именно приложения, то этого нет), да и то это отмирает (скорее ИМХО)...

Насчет eval: RFC ты явно не читал.

Только просмотрел указанные тобой ссылки, но не вижу ничего, что противоречило бы моим высказываниям про eval, можешь кусок запостить, чтоб не про описание в общем говорить?

А если у него и электричества нет?

и все же это минус, хотя и небольшой

Ты меня извини, но кажется, что ты порой сравниваешь несравнимые вещи. Например, припомню тебе WSDL  Это не протокол RPC, а средство описания RPC-сервисов без привязки к определенному транспорту и протоколу (привязка осуществляется самим WSDL)

Давай разберемся (в споре рождается истина), что ты имеешь ввиду под протоколом применительно к WSDL (пример)? И где я делал привязку к транспорту?

В одном файле можно описать сервисы SOAP, DCOM, JSON-RPC, XML-RPC и все что угодно - что там еще напридумывали (лишь бы клиент это поддерживал).

Я этому и не противоречил. Слово "файл" тут ммм немного кривовато...

Не понял, при чем тут WSDL? То, что это XML формат? И как существование JSON дискредитирует WSDL?

:)WSDL дискредитирует сам контент статьи, а не существование JON

[lapulya]

sss,

Какой поставщик данных? Я вызываю методы объектов

Ну в случае DCOM на клиентской стороне генерится враппер, методы которого вызываются, напиши враппер и все дела!

Блин, для программиста нет особой разницы - DCOM или COM.

Разница в скорости (причем на порядки), так что программист только в глубокой теории не зависит от того, что он использует COM и DCOM, попробуй ка используй DCOM для обработки потокового видео, сразу поймешь о чем речь!

Показатель успешности в таких вещах один - объем отжираемых бабок. И всё...

вот, вот, а теперь прикинь, что будет если у тебя поставщик данных (сервер) старый/новый по отношению к клиенту, правильно ничего не работает, а в случае WSDL, JSON нет проблем (ну не на 100%, потому как данные могут быть критичными к логики обработки, но если это "пассивные" данные, для отображения например, то нет проблем, а таких данных бывает не мало) и это только один пример "отжираемых бабок".

[RXL]

ЭЭЭЭ ну чего сказать... DCOM отстой WSDL рулит)))) кто против?

а в чем прелесть по сравнению с WSDL? мы с клиента асинхронно (в случае тонкого клиента) запрашиваем вебсервис. ....

А статью надо подкорректировать, иначе это просто дискредитация WSDL .

2. скорость работы (кстати возможно по этому параметру WSDL, JSON тут не прокатят, хотя если данные паковать...)

Надергал со всей темы. Если где пропустил, то уж извиняйте - и этого достаточно.
lapulya, ты постоянно приравниваешь WDSL к RPC-протоколам. Это как сравнивать меню и сам обед: список блюд - это еще не еда. JSON - тоже не протокол, но рядом с WDSL его поставить нельзя, т.к. разные это вещи.
Как только перестанешь вносить путаницу, так. сразу появится время на саму суть беседы, а не на переливание из пустого в порожнее.


XML-RPC появился в 1998 году. В какой-то мере это можно считать "зарей эпохи", но он все еще в строю и успешно применяется. Главный его плюс над SOAP - простота и компактность. Т.е. если бы я сравнивал SOAP и JSON-RPC, то выигрыш в объеме был бы не в 2 раза, как я упомянул в статье, а раз в 10.

[lapulya]

RXL, RPC у меня в половине случаев свой (там где обращение идет к самой странице), а в половине случаев это протокол майкрософтовских веб сервисов (т.е. то что в MS называется webservice).

Использовал не только для weba, но и для framework (там, ясное дело, использовался протокол майкрософт)

Не вижу "переливания"

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

Итого, все что я сказал выше верно. Когда речь шла о формате данных, я писал о формате данных, когда о вызове, о вызове. Различия в объеме пересылаемых данных не более 15% (json выигрывает), в читаемости и разборе - json проигрывает.

[sss]

lapulya, блин, что значит свой RPC? Если я написал одно приложение, в котором серверная часть парсит командную строку и выполняет некие действия - это RPC? А как же генераторы оберток, позволяющие использовать RPC (LPC) со всеми вытекающими последствиями: Моникеры? Маршаллинг? Пространство имен и точки подключения? Аутентификация и безопасность?

[lapulya]

sss, хехе,
1. протокол и его реализация друг с другом не связаны (да и реализации могут быть разные, и по "навороченности" сильно отличаться)
2. сам протокол не обеспечивает аутентификацию, безопасность и т.д.
3. почему должна быть именно генерация обертки? У меня есть механизм который позволяет обработчикам подписываться на вызовы удаленной стороны (т.е. никакой генерации нет), это что уже не протокол?

По приходу данных с удаленной стороны (фактически это вызов удаленной процедуры) механизм производит разбор данных и производится вызов, если есть подписанный обработчик на данный вызов, то он отрабатывает (ему передаются пришедшие параметры), после чего возвращаемое значение отправляется удаленной стороне. Чего ж тебе еще надо? Чистой води RPC протокол.

Причем тут моникеры, маршалинг и т.д.? Да я  вообще мог бы (если бы протокол DCOM был открыт) "руками" генерировать вызов удаленной процедуры, сформировав необходимый поток данных и отправив их на удаленный хост, это что уже не протокол RPC (хотя обертки то нет, нет и всего остального)?

Есть у меня нечто имеющее функцию "f", можно дернуть ее локально, можно удаленно. Удаленно дергается так: надо отправить туда-то строку "call:f" и при этом будет вызвана функция "f" у этого нечто. Все! Вот это уже и протокол RPC (описание формата вызова, опуская передачу параметров и возвращаемого значения и их типизацию) и его реализация!!!

[sss]

lapulya, мне надоело честно... Нет протокола RPC. Есть технология COM/DCOM, решающая внутри себя такие задачи RPC, как, генерация врапов,  маршалинг, безопасность и т.д. Что значит навороченность? Если вы живете в современном мире с его проблемами - извольте их решать.

[lapulya]

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

Да, я живу в современном мире и в ряде случаев (а при разработке web приложений они почти все такие) мне более чем достаточно в моих приложениях:
1. руками сформировать обращение (отработать как маршаллер и это нормально, поскольку это так же быстро, как и написать вызов враппера) к удаленному методу, генерация полного обращения (это уже просто HTTP запрос, в который вставляется серилизованные данные) к удаленной стороне занимается внешняя библиотека (но ее так же мог написать и я, там ничего крутого нет)
2. принять и разобрать сообщение на удаленной стороне общим механизмом (написан для этой цели и используется всеми сервисами)
3. дернуть подписанный на данный вызов (тот что принят в п.2) метод, передав ему все пришедшие параметры, если таковой метод имеется.
4. отправить результат обратно
5. получить и обработать результат на клиентской стороне.

ВСЕ! Не надо так возмущаться и напрягаться не нужен мне DCOM, не нужен (кстати, что мне с DCOM делать если у меня сервер на Unix)!

ЗЫ
Чтобы от одного подъезда дома добраться до соседнего подъезда мне не надо вызывать грузовое такси с краном для погрузки багажа (который я не напрягаясь донесу в кармине), мне достаточно скейтборда, который стоит у моей двери и заказывать и ждать мне ничего не надо.

[sss]

lapulya, возмущает оценка технологии. Причем почему то тебе кажется, что DCOM/COM предназначен тупо для доступа к базам данных...
Сразу признаюсь - ничего не знаю про UNIX, но все таки, там  нет серверов автоматизации,  да?

[lapulya]

sss, ты меня с кем то путаешь, я про базы данных ни слова не сказал (причем они тут я тоже не понимаю)... RPC есть RPC... тут область применения рояля не играет, механизм работает для любой функции хоть для БД, хоть для музыки, хоть для графики, для расчетов, да для чего хочешь.

Про Unix я сказал с тем умыслом, что MS сама для Unix ничего не пишет (насколько я знаю), а протокол DCOM закрытый, стало быть поддержки DCOM на Unix машинах (да и на маках и остальных платформах) я думаю нет (не уверен, но скорее всего нет). А вот SOAP, JSON и т.д. протоколы открытые и могут использоваться на любых платформах и любых приложениях.

[RXL]

Мужики, не надо друг друга убеждать. Лучше расскажите о своем опыте применения, об особенностях, о трудностях.

[The Nameless One]

Все как-то забыли о DirectX, который благодаря COM имеет обратную совместимость. И, скажем, если у пользователя стоит DirectX 11  в системе, он сможет без проблем насладиться приложением (игрой - классикой, к примеру), написанным на DX 8, DX 9, DX 10. На любом.
ИМХО - это и есть преимущество COM -  разве нет?

[RXL]

The Nameless One, COM не имеет никакого отношения к совместимости версий DX.

[The Nameless One]

Почему не имеет? DX же использует COM модель.
_{я дилетант в этих вопросах}

[RXL]

The Nameless One, и что из этого? Бутылки 0.5 и 0.7 тоже обратно совместимы, но не используют COM.
Поддержка старых интерфейсов целиком на совести DX.

[The Nameless One]

RXL, спасибо что развеяли моё заблуждение касательно этого вопроса

[sss]

Не... RXL не прав... Использование COM - очень удобно разработчикам и пользователям... Пользователь библиотеки не заботиться не об ее названии, ни об системе, в которой она установлена... Разработчики уверены - кто использовал однажды продолжит использовать, старые коды работают... И именно DirectX в этом плане яркий представитель успешной библиотеки....

[RXL]

sss, чем я не прав? Прошу цитировать, а то не понятно, о чем речь.

[lapulya]

Согласен с RLX, какое отношение успешность (тут еще можно указать много эпитетов, в том числе и скорость работы, удобство использования, и т.д.) библиотеки имеет к COM, как к технологии? Это могла быть и просто обычная dll...

[sss]

Извиняюсь...

The Nameless One, COM не имеет никакого отношения к совместимости версий DX.

Вот пример. Я один раз написал программу, использующую COM интерфейсы AutoCAD 2002 в Win98. Она прекрасно работает и в AutoCAD 2010 в Windows7.

P.S.: Вообще не хотел ввязываться в разговор, но опять не удержался.

[RXL]

sss, понятно. Под версиями я не имел в виду разные версии ОС, а только версии интерфейсов.

[lapulya]

sss, все же я не понимаю причем тут COM? Да, DX достаточно качественный продукт, работает под разные поколения ОС и поддерживает старые версии и что? Это всего навсего качественная библиотека, которая могла, как опираться на технологию COM, так и нет... вот есть user32.dll, она обладает теми же достоинствами и не является COM сервером.

[sss]

lapulya, то же самое можно сказать:
 - зачем мне C++? Я всё могу сразу замутить в HexView. Код написанный в C++ это всего навсего набор машинных команд.

[WDMclient]

Я тут пока не выхожу из КОМы.

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

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

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

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

[lapulya]

sss, не согласен, COM как и dll это механизмы призванные для того чтобы 100 раз не писать один и тот же код в разных приложениях (так называемое повторное использование). Да, у ком есть еще и то достоинство, что он в нем реализован RPC, но если все умещается на одной машине это роли не играет. Учитывая сказанное выше сравнивать COM и dll абсолютно корректно.

Если же речь идет о работе с компонентами на удаленной машине, тут другое дело, но раз речь шла о DX, то в 99,9% случаев будет использована только локальная машина, а тут у COM преимуществ имхо нет (если есть, прошу их перечислить).

зачем мне C++? Я всё могу сразу замутить в HexView. Код написанный в C++ это всего навсего набор машинных команд.

не принимается, на с++ в отличии от HexView удобно писать, проектировать и т.д. и т.д., а COM и dll в этом плане одинаковы, точнее даже преимущество полностью на стороне dll (ну понятное дело если программа написана целиком на с++ или ему подобном языке, а не предположим на VB, где с dll как раз сильно неудобно, но иногда можно, вот тут как раз сравнение с++ и HexView вполне корректно). Преимущества, если надо, хотя они и очевидны, я могу расписать...

[lapulya]

WDMclient, COM очень много всего навязывает, внешний интерфейс dll (импорт экспорт определенных функций) + формат внешних интерфейсов объектов (QueryInterface и т.д.) + формат внешних данных (иногда, если предполагается работать с VB и т.д., это я о VARIANT). Если с VB и им подобными работать не предполагается (и не будет использоваться RPC), то имхо COM сервер ничем от DLL не отличается, но есть ряд ограничений обусловленный предначертанными интерфейсами.

[WDMclient]

Сила С++ проявляется только если используешь интерактивную оболочку
Visual Studio или Борланд "студио" , скорость разработки повышается от того
что поставил стрелочку от указателя или точку и тебе выпал список переменных ,
и функций. Вот и все преимущество и не надо убеждать что типа магия в классах и других фичах.

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

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


Вот таким же образом работает и COM.  Делаешь #import  .tlb
и по быструхе с со смарт-указателем работаешь.

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

На коме не делаются скоростные программы ,  тут другие задачи.
которые должны отрабатывать тупо и надежно.
 
- web-money -КОШЕЛЕК ,(требуют постоянных изменений)(безопасность понимашьли)
 
- активы-иксов (это знают все)

- компилятор-Лисп (а я емаЁ взял да и просоеденил его к тому редактору который хотел)






Программирование COMов - это игра в конструктор , где можно быстро заменять детали.

[lapulya]

lol

[sss]

lapulya, сравнивать общий принцип использования библиотек dll с технологией COM, которая тоже использует dll, это бред. Поэтому я ввел сравнение с машинными кодами... А вот то что написал WDMclient - сказано  довольно точно и в общем я поддерживаю.

[lapulya]

sss, сравнивая COM с dll я имел ввиду, что COM избыточен для тех случаев что я описал (все пишем на с++ и на одной машине), фактически он лишь мешает (причем по всем параметрам), а не помогает, какая от него польза, ну перечисли хоть что-то? Я не вижу ни одного плюса, а то, что есть хорошие библиотеки написанные как COM сервера аргументом не считается, по упомянутым выше причинам (там где про DX написано)

не могу считать серьезным последний пост WDMclient, с чем ты там согласен конкретно, кроме последней фразы?

Программирование COMов - это игра в конструктор , где можно быстро заменять детали

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

Поймите меня правильно, я не хочу тут сказать, что COM это говно куда ни копни, я лишь хочу сказать, что при указанных мной ограничениях COM лучше НЕ использовать, ибо нет от него плюсов, просто делаем обычную dll. Если же надо перекинуть например модуль на удаленный хост или воспользоваться модулем из VB, нет проблем, пишем COM враппер (т.е. COM сервер, который не содержит логики и просто транслирует вызовы этой dll и распространяется с ней) ил,и если это ясно изначально (это я про Vb или удаленный хост), вот тогда можно писать COM сразу (хотя имхо я бы и так не делал, а сначала бы опять сделал просто dll).

[WDMclient]

1.У меня ни дня не проходит что бы какой нить ActiveX не загружался с интернета.
  (по непонятным причинам Java проиграл борьбу за клиент-интернет )
2.COM - будет существовать потому как того хочет Майкрософт
3.Не вижу причин не работать с COM (Ведь под этим словом подразумевается куча всяких интересных механизмов, доведенных по своей структуре до весьма искусного(чуть ли не научного) порядка)
конечно можно сделать тоже самое и своими руками  , но получилось бы только жалкое подобие , размазаный комок грязи представлял этот код( потому как время для этого надо и несколько голов)
Те спецы что отрабатываели и тестировали COM , не зря время теряли , и теперь имеем еще одну
технологию ,
чем больше технологий , тем богаче мир программирования , тем больше шансов проявить себя тому у кого есть мозги и желание учиться.

4.У всех технологий есть плюсы и минусы.
   Но если ты изучил технологию тогда большой тебе плюс ,( и большая вероятность
   получить за это бабла)

5.Есть гипотеза что новые приемы в программировании появляются , когда
   разработчикам становиться СКУЧНО.

[RXL]

А если отвлечься от COM и поговорить об опыте использования других технологий удаленного вызова? Как предложение.

[x77]

коллбэки в длл - рулят форева и в топку микрософт.

[RXL]

Игор, уточни — callback на другой сервер?

[WDMclient]

The Nameless One, и что из этого? Бутылки 0.5 и 0.7 тоже обратно совместимы, но не используют COM.
Поддержка старых интерфейсов целиком на совести DX.

Я как(мультифридный клиент) заметил что не все бутылки 0.5 и 0.7 можно сдать обратно (кэлбэк не проходит)
Совместимость  с приемным пунктом(а часто это бывает синглтонный сервер) не всегда поддерживается последним.

Бывает после длительного маршалинга приходится во свояси чесать интерфейс  в
раздумье над своим IConnectionPoint(ом)  
в общем вместо ожидаемого поъема счетчика настроения приходится вызывать очередной Релиз ,  не редко с критическим вылетом  на неделю из процесса вменяемого функционирования со сменой  аппартаМЕНТОВ.

[x77]

Игор, уточни — callback на другой сервер?

зачем на другой? на свой.

есть два варианта, да?

1. клиент живёт локально, а на удалённом хосте работает сервис, обрабатывающий удалённые запросы и дёргающий нужные длл. так будет работать SOAP, например, если мы напишем на нём классический веб-сервис. и так же работает КОМ, соап - это просто надстройка над комом, позволяющая передать по http ком-объект. и вообще любой объект.
2. клиент живёт локально, и длл живёт локально, и клиент её дёргает, а она уже сама знает, куда ей ломится и что там делать. так работает всё остальное и для этого вообще изначально были придуманы длл - вынести повторяющуюся либо часто меняющуюся часть кода отдельно.

парадокс всех этих новых технологий в том, что время, требующееся для их уверенного использования НА ПОРЯДКИ превышает время, которое уйдёт у среднего программера на написание тупого TCP/IP сервера со своим клиентом. который будет делать всё то же самое, но при этом будет быстрее, на порядки проще в отладке, не требовать ахиренной квалификации для дальнейшего сопровождения и доработки, и т.д.

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

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

[RXL]

А никому, случайно, не приходилось работать с COM из PHP?
Имею траблу типа "type mismatch" с полным не пониманием, что тут не совпадает...

Если сторонняя библиотека, написанная на VB.

Описание метода VB:

Код:

Public Function Logon( _
   ByVal LogonID As String, _
   ByVal Password As String, _
   ByRef DataSourceName As String, _
   ByRef Result As String, _
   ByRef Severity As Integer _
) As Boolean

Код:

  $ctx = new COM('some_com_class');
  $user = 'login';
  $pswd = 'password';
  $dsn = 'some_dsn';
  $result = '';
  $severity = 0;
  $retcode = $ctx->Logon($user, $pswd, $dsn, $result, $severity);

Объект создается без вопросов.

Перехватываю исключения:

COM exception: exception 'com_exception' with message 'Parameter 0: Несовпадение типов.' ...

Голову уже сломал. Пробовал всякие извраты с "new VARIANT(....)".
Два часа рою инет и никакого намека.

PHP 5.2.12 Win32.

[Sla]

попробуй
ByRef Severity As Integer

ByRef Severity As String
а потом преобразовать в integer средствами VB

[resource]

А там что, параметры с конца исчисляются?

[sss]

RXL, как инициализируешь ByVal As String ? В смысле чему равен vt и bstrVal ?

Код:

VARIANT v1;

v1.vt = VT_BSTR;
v1.bstrVal = SysAllocString( "some text");
SomeMethod( v1);
SysFreeString(  v1.bstrVal);

В PHP аналогично можно сделать? Пропуская строку через SysAllocString, ты ее готовишь к маршаллингу...

P.S.: SysAllocString можно заменить на CoTaskMemAlloc...
P.P.S: CoTaskMemAlloc можно достать и через COM объект интерфейа IMalloc...

[RXL]

Sla, библиотека сторонняя - менять ничего не могу.

resource, сам удивляюсь...

sss, я просто передаю переменную.
В PHP можно создать Variant. Я пробовал так:

Код:

  $ctx = new COM('some_com_class');
  $user = new VARIANT('login');
  $pswd = new VARIANT('password');
  $dsn = new VARIANT('some_dsn');
  $result = new VARIANT('');
  $severity = new VARIANT(0);
  $retcode = $ctx->Logon($user, $pswd, $dsn, $result, $severity);

Ошибка меняется:

COM exception: exception 'com_exception' with message 'Parameter 2: Несовпадение типов'.

Потом так:

Код:

  $ctx = new COM('some_com_class');
  $user = new VARIANT('login', VT_BSTR);
  $pswd = new VARIANT('password', VT_BSTR);
  $dsn = new VARIANT('some_dsn', VT_BSTR);
  $result = new VARIANT('', VT_BSTR);
  $severity = new VARIANT(0, VT_I2);
  $retcode = $ctx->Logon($user, $pswd, $dsn, $result, $severity);

Ошибка та же - на второй параметр.

Последовательно меняю:

Код:

  $ctx = new COM('some_com_class');
  $user = new VARIANT('login', VT_BSTR);
  $pswd = new VARIANT('password', VT_BSTR);
  $dsn = 'some_dsn';
  $result = new VARIANT('', VT_BSTR);
  $severity = new VARIANT(0, VT_I2);
  $retcode = $ctx->Logon($user, $pswd, $dsn, $result, $severity);

COM exception: exception 'com_exception' with message 'Parameter 1: Несовпадение типов'.

Код:

  $ctx = new COM('some_com_class');
  $user = new VARIANT('login', VT_BSTR);
  $pswd = new VARIANT('password', VT_BSTR);
  $dsn = 'some_dsn';
  $result = '';
  $severity = new VARIANT(0, VT_I2);
  $retcode = $ctx->Logon($user, $pswd, $dsn, $result, $severity);

COM exception: exception 'com_exception' with message 'Parameter 0: Несовпадение типов'.

Похоже, что дело в $severity. Только не понимаю, в чем...

[sss]

Вот как надо в C++

Код:

  short    i;
  VARIANT  var;
  var.vt = VT_BYREF | VT_I2;
  var.piVal = &i;
  SomeMethod(  var);

В PHP не знаю!

[RXL]

Код:

  $severity = new VARIANT(0, VT_I2 | VT_BYREF);

COM exception: exception 'com_exception' with message 'Variant type conversion failed: Несовпадение типов.

[sss]

RXL, VT_I4 ? И, может быть, первый аргумент в  VARIANT( 0, xxx) не 0 а адрес на переменную?

[lapulya]

а аналогичный по смыслу с++ код работает? Т.е. вопрос в следующем - сам ком сервер работает?

[RXL]

Пробовал и такие варианты...


Работает. Объект создается. Если я укажу в методе Logon иное число параметров, он ругается, что их число слишком велико или что пропущен важный параметр - значит с этим все путем.

Объект в VB6 и в ASP создается без проблем.

[Sla]

а пробовал параметры слева-направо передать?

[resource]

Я вот об этом же подумал. Раз они наоборот передаются, этож не значит, что они принимаются наоборот. Значит надо передавать по-другому

[RXL]

В обратном порядке не может быть. Конечно, попытка не пытка, но результат был очевидный


Вот трассировка исключения, если убрать все "new VARIANT":

Код:

  array(1) {
    [0]=> array(6) {
      ["file"]=> string(31) "D:\Work\src\www\tests\com_1.php"
      ["line"]=> int(43)
      ["function"]=> string(5) "Logon"
      ["class"]=> string(3) "com"
      ["type"]=> string(2) "->"
      ["args"]=> array(5) {
        [0]=> string(5) "login"
        [1]=> string(4) "pass"
        [2]=> &string(3) "dns"
        [3]=> &string(0) ""
        [4]=> &int(0)
      }
    }
  }

По аргументам видно, что первые два передаются по значению, а последние три - по ссылке. Т.е. так, как требует документация.

[RXL]

Все еще бьюсь над разгадкой.

Есть такая функция - com_print_typeinfo($com_object). Она распечатывает класс, автоматически создаваемый PHP для COM-объекта. Вот описание метода Logon() оттуда:

Код:

	/* DISPID=1610809554 */
	/* VT_BOOL [11] */
	function Logon(
		/* VT_BSTR [8] [in] */ $LogonID,
		/* VT_BSTR [8] [in] */ $Password,
		/* VT_PTR [26] [in][out] --> VT_BSTR [8]  */ &$DataSourceName,
		/* VT_PTR [26] [in][out] --> VT_BSTR [8]  */ &$Result,
		/* VT_PTR [26] [in][out] --> VT_I2 [2]  */ &$Severity 
		)
	{
	}

Даже не знаю... Может оно мне чем-то помочь? Мозг уже не видит, какие варианты еще можно попробовать.

[sss]

RXL, а откуда берется VT_I2 ? В MSDN про Integer Data Type (Visual Basic) пишут

"Holds signed 32-bit (4-byte) integers ranging in value from -2,147,483,648 through 2,147,483,647"...

[RXL]

sss, в VB6 (не VB.NET!) тип Integer соответствует short int, а Long - int.

Использовать VT_I4 я уже пробовал.

[sss]

RXL, ну не знаю. Попробуй установить все в NULL...

Код:

  var.vt = VT_ERROR;
  var.scode = DISP_E_PARAMNOTFOUND;

[RXL]

Тогда смысла не будет. Кстати, scode у меня нет - только значение и тип.

Вот порылся в доках:

Overloaded Methods
The returned object is an overloaded object, which means that PHP does not see any fixed methods as it does with regular classes; instead, any property or method accesses are passed through to COM.

Starting with PHP 5, PHP will automatically detect methods that accept parameters by reference, and will automatically convert regular PHP variables to a form that can be passed by reference. This means that you can call the method very naturally; you needn't go to any extra effort in your code.

In PHP 4, to pass parameters by reference you need to create an instance of the VARIANT class to wrap the byref parameters.

Честно говоря, не понимаю, как стыкуется заголовок и первый абзац к другим двум абзацам.

Во втором абзаце говорится, что выпендриваться не нужно - просто подавай переменные и PHP сам все разрулит. В третьем - о том, как было в PHP 4.
Я пробовал и так и сяк - не хочет. Больше всего сбивает с толку нумерация параметров - не могу точно локализовать источник проблем. Думаю о всех трех параметрах BYREF, но манипуляции с VARIANT мне не помогли.

[RXL]

Решил я на это забить. Все равно, коли есть винда, то и ASP на ней работает, а из ASP проблем с COM нет.

а аналогичный по смыслу с++ код работает? Т.е. вопрос в следующем - сам ком сервер работает?

Это сторонний софт, который работает этак лет 10 уже. Последние 4 года сервис написан на VB.NET (.NET 1.1), а до этого - на VB6. Интерфейсом к софту являются три COM-библиотеки.
Из Borland C++ Builder 6 я успешно с ним общаюсь (классовая обертка автоматически сгенерена в Delphi 7). Также работаю с ним из VB6 и ASP (JavaScript). А вот в PHP5 работать отказывается. И дальше уйти не могу, т.к. сперва нужно залогиниться на сервере приложений, а это мне никак не удается из-за непонятной ошибки с параметрами.

[RXL]

Два года спустя вернулся к той же задаче. Перерыл инет и нашел все тоже самое: эту тему и один совет - все остальное просто мусор. Совет простой: написать свой COM на VB, где реализовать всю необходимую логику и простой интерфейс, совместимый с PHP. Первые тесты уже дали положительные результаты. Когда напишу что-то посерьезнее logon/logoff отпишусь здесь. А то тенденция: в инете полезная инфа пропадает, а здесь - скапливается.

[Dimka]

RXL, web-service на ASP.NET как надстройка над твоим COM, а с веб-сервисом PHP по SOAP+WSDL всяко договорится Конечно, если это не высоконагруженное приложение.

[RXL]

Нет, не нагруженное. Для каждого запроса к сервису нужно создавать COM-объект, вызывать logon (на сервере DCOM-приложений создается новый процесс), затем там же создаются кучи других объектов. Несколько секунд на каждый запрос.

Я пока рассматриваю вариант VB6+PHP. Не хочу привязываться к IIS.

[Dimka]

RXL, тогда WCF.NET, у неё хост может быть любой: хоть IIS, хоть собственный exe, хоть служба WinNT. А функции те же, и HTTP поддерживает, и другие протоколы.

[RXL]

Проверил: мои беды были из-за VB6 типа Integer, а при использовании Long программа без проблем работает. Также работает передача ByVal и ByRef. Тестил на WinXP SP3 с PHP 5.2.17 оригинальной сборки (VC6).