Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.
Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.
Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое.
Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете?
Может быть проще будет реализовать межпроцессорное взаимодействие самому?
Здравствуйте, _kaimonomah_, Вы писали:
__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента. __>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение. __>Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое. __>Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете? __>Может быть проще будет реализовать межпроцессорное взаимодействие самому?
__>Возможно кто-то сталкивался с подобными задачами.
__>Спасибо.
Если плата ваша то определитесь с потоком данных и где по отношению к клиенту она
будет находиться, а то может так оказаться что придется использовать
собственный протокол на UDP ( если это конечно распределенная система )
или простую буфферизацию в память / файл
а так можете пользовать что больше нравится и в чем разбираетесь
если это готовый девайс то посмотрите какие решания предлагает разработчик
Здравствуйте, _kaimonomah_, Вы писали:
__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента. __>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.
Почему не WebServices? Или на сервере нужна какая-то хитрая объектная модель?
... << RSDN@Home 1.2.0 alpha rev. 786>>
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Давать конкретную рекомендацию сложно, так как спеков не достаточно. Советую посмотреть вот на эти подходы:
1) http://www.zeroc.com/ice.html
2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).
Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.
Здравствуйте, novitk, Вы писали:
N>Давать конкретную рекомендацию сложно, так как спеков не достаточно. Советую посмотреть вот на эти подходы: N>1) http://www.zeroc.com/ice.html
спасибо, посмотрю.
N>2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).
А как со скорость. Я слышал что WebService достаточно медленно работают.
N>Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.
Здравствуйте, _kaimonomah_, Вы писали:
TK>>Если по простому — RPC/Обмен сообщениями. с кроссплатформенностью — сложнее сказать где их нет. __>А какие преимущества у WebService перед COM или CORBA?
Простота, широкая доступность и не завимость от поставщика.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, _kaimonomah_, Вы писали:
N>>2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).
__>А как со скорость. Я слышал что WebService достаточно медленно работают.
Да, SOAP тормоза еще те. При гибридном подходе (http+бинарная сериализация) можно приблизится по скорости к CORBA. Если все равно медленно, надо переходить на UDP, но интероп перестает быть дешевым.
N>>Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.
__>Если рассматривать TAO (The ACE ORB) реализацию?
Никогда не использовал, но слышал о ней хорошие вещи. Советую написать еcho-server и проверить со следушими клиентами: .NET(http://iiop-net.sourceforge.net/), JDK(используя встроенный ORB) и Python(http://omniorb.sourceforge.net/). Не должно занять больше дня.
Здравствуйте, _kaimonomah_, Вы писали:
__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.
Из личного опыта: У нас стояла задача получить данные с 22 устройств находящихся на большлм уделении друг от друга. Данные с устройств считывались с помощью контроллеров ipc con.
__>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение. __>Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое.
Данные с контроллеров получает OPC- сервер по протоколу modbus. Причем клиенты должны получать информацию через web-интерфейс.
Задача была решена немного многозвенно,но все же: клиент опрашивает opc- сервер и держит инфу по всем устройствам в памяти.
Клинты наблюдают данные через web-интерфейс, который(сайт) в свою очередь забирает данные через веб-службу, а веб- служба забирает данные у opc- клиента. Веб-служба и opc-клиент взаимодействуют через .net remoting.
Почему веб- служба: потому что кроме веб-интервейса есть программа написанная для кпк, которая также получает данне через веб-слжубу.
__>Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете? __>Может быть проще будет реализовать межпроцессорное взаимодействие самому?
Кросс-платформенность вообще нужна???
__>Возможно кто-то сталкивался с подобными задачами.
__>Спасибо.
Здравствуйте, _kaimonomah_, Вы писали:
__>Здравствуйте, RobertSZ, Вы писали:
RSZ>>Кросс-платформенность вообще нужна???
__>Очень желательно, т.к. в дальнейшем возможно придется строить систему на базе *nix
Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.
Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (
RSZ>Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.
RSZ>Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (
А разве существует OPC спецификация для *nix систем? Вроде OLE for Process Control. Привязана в Windows.
Здравствуйте, _kaimonomah_, Вы писали:
__>Здравствуйте, RobertSZ, Вы писали:
RSZ>>Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.
RSZ>>Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (
__>А разве существует OPC спецификация для *nix систем? Вроде OLE for Process Control. Привязана в Windows.
мда...честно говоря я не задумывался))
ну да ладно....
тогда все равно рекомендую контроллеры с поддержкой протокола modbus. просто твоя программа сервер будет отправлять на контроллер запросы как opc-сервер и получать ответы.
Здравствуйте, RobertSZ, Вы писали:
RSZ>мда...честно говоря я не задумывался))
RSZ>ну да ладно....
RSZ>тогда все равно рекомендую контроллеры с поддержкой протокола modbus. просто твоя программа сервер будет отправлять на контроллер запросы как opc-сервер и получать ответы.
Вычитал, что новая спецификация OPC строится на базе Web Serivce. Реально ли их создавать на C++ (без титанический усилий типа COM на Си)?
На чём они обычно пишутся?
Re[7]: COM, CORBA, RPC что быбрать?
От:
Аноним
Дата:
17.01.08 12:57
Оценка:
Здравствуйте, _kaimonomah_, Вы писали:
__>Вычитал, что новая спецификация OPC строится на базе Web Serivce. Реально ли их создавать на C++ (без титанический усилий типа COM на Си)? __>На чём они обычно пишутся?
Сделайте на XML-RPC.
1. Абсолютно кросплатформенно
2. Высокая скорость (при использовании boxcarring'а -- зверская)
3. Доступны библиотеки для всех, сколь нибудь популярных, ЯП (для C/C++ -- http://xmlrpc-c.sourceforge.net/)
4. Доступность всех прелестей транспорта HTTP (сжатие, шифрование)
5. Простота отладки взаимодействия клиента с сервером (любой снифер, пакеты легко читаются человеком)
6. Бинарные данные можно передавать без кодирования (зависит от библиотеки, впрочем)
__>>А как со скорость. Я слышал что WebService достаточно медленно работают.
N>Да, SOAP тормоза еще те. При гибридном подходе (http+бинарная сериализация) можно приблизится по скорости к CORBA. Если все равно медленно, надо переходить на UDP, но интероп перестает быть дешевым.
Можно ещё WCF или Remoting. Первый относительно кросплатформенное решение. Второе — нет.
Зато оба работают и с SOAP и с бинарными форматами по любым каналам. Производительность высокая. WCF на IIS7 заявлено быстрее WebServices причём и жавовских тоже. Remoting — на уровне COM+ (принцип тот же), т.е. ещё выше.
