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.