Чем мы заменим связь DCOM?

Question

В настоящее время у нас есть несколько приложений C ++ / MFC, которые общаются друг с другом через DCOM.Теперь мы будем обновлять приложения, а также захотим заменить DCOM на что-то более современное, с чем проще работать.Но мы не знаем что.Как вы думаете

Редактировать

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

Answer 1

существует множество библиотек сообщений C ++, от старых ACE до новых, таких как буферы протокола Google или Facebook (теперь Apache) Thrift или Cisco Etch .

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

Answer 2

DCOM - не что иное, как сахарное покрытие в системе обмена сообщениями.

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

В настоящее время есть два типичных способа сделать это:

• Чистая система обмена сообщениями, например, с использованием GoogleБуферы протокола как формат обмена
• Веб-сервис (либо полный веб-сервис в JSON, либо REST API)

Answer 3

Я делал много приложений на C ++ и Java, используя REST, и я очень доволен. Несмотря на сложность CORBA и SOAP, REST прост в реализации и гибок. У меня была некоторая кривая обучения, которую Гед использовал для моделирования вещей как CRUD, но теперь это кажется еще более интуитивным.

Теперь для стороны C ++ я не использую определенную библиотеку REST, просто cURL и синтаксический анализатор XML (в моем случае, CPPDOM), потому что приложения C ++ являются только клиентами, а серверы - Java (используя платформу Restlet). ). Если вам это нужно, есть еще один вопрос здесь, в SO, который рекомендует:

Может кто-нибудь порекомендовать хороший C / C ++ RESTful Framework

Я бы также упомянул, что мое решение использовать XML было произвольным, и я серьезно подумываю заменить его на JSON. Если у вас нет особой потребности в XML, JSON проще и легче. И прелесть REST в том, что вы можете даже поддерживать оба вместе с другими представлениями, если хотите.

Answer 4

Это зависит от многих факторов. Его можно просто заменить на .NET remoting . Кроме того, если вы собираетесь предоставлять услуги для других компонентов более стандартным способом, Web Services будет хорошим выбором.