Автоматизация внешних приложений

kasa · Сообщение **kasa** » 04 сен 2008 02:05

Здравствуйте!

Пытаюсь разобраться, каким образом можно автоматизировать мое внешнее приложение. Возникли вопросы.
В архиве SDK нашел два документа: OnAirExternalTaskMsg.doc и SLMessageServerSDK.doc.
Каким из них следует пользоваться?
Интуитивно, конечно, понятно, что надо использовать сервер сообщений, но хотелось бы услышать подтверждение.
Или, может, есть еще какой способ?

В описании сервера сообщений сказано, что он является COM-сервером. Является ли он так же полноценным DCOM-объектом?

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

Спасибо.

Даниленко Сергей

каким образом можно автоматизировать мое внешнее приложение.

А не могли бы вы вкратце объяснить что именно делает ваше внешнее приложение?

В архиве SDK нашел два документа: OnAirExternalTaskMsg.doc и SLMessageServerSDK.doc. Каким из них следует пользоваться?
Интуитивно, конечно, понятно, что надо использовать сервер сообщений, но хотелось бы услышать подтверждение.
Или, может, есть еще какой способ?

Так же интуитивно порекомендовали бы вам использовать SLMessageServerSDK. Но точнее можно сказать после вашего ответа на первый вопрос - что делает ваше приложение?

В описании сервера сообщений сказано, что он является COM-сервером. Является ли он так же полноценным DCOM-объектом?
Дело в том, что мой софт будет установлен не на той машине, где стоит сервер. Соответственно, мне нужно ловить команды по сети.
Смогу ли для этого воспользоваться уже готовым решением, или придется писать доп. локальное приложение для сервера?

SLMessageServerSDK был выделен в свободное распространение в ходе создания возможности "зеркалирование" в программе Onair. Эта возможность ("зеркалирование") подразумевает, что все действия оператора в OnAir на одной машине автоматически повторяются в программе OnAir, которая запущена на другой машине.
Соответственно SLMessageServerSDK удовлетворяет вашим требованиям.
Вообще SLMessageServerSDK - это протокол и набор API для общения внешних приложений с программой OnAir (в обе стороны).
Пример (наш) - на таком подходе программа SLFileForwarder взаимодействует с расписанием программы Onair.
Последний набор SDK здесь:
http://www.softlab-nsk.com/rus/forward/download.html

kasa · Сообщение **kasa** » 04 сен 2008 10:40

А не могли бы вы вкратце объяснить что именно делает ваше внешнее приложение?

Хм, а разве это имеет значение?

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

SLMessageServerSDK был выделен в свободное распространение в ходе создания возможности "зеркалирование" в программе Onair. Эта возможность ("зеркалирование") подразумевает, что все действия оператора в OnAir на одной машине автоматически повторяются в программе OnAir, которая запущена на другой машине.

Из беглого изучения вопроса это не следует. Ибо, очередь активизируется посредством обычного оконного сообщения.
Мне не понятно, как оно попадет на другую машину. Или это реализовано внутри proxy/stub COM-сервера?
Тогда не понятно, зачем использовать сообщения, а не реализовать через механизм connection points?
Может я чего не там читаю? Или у меня СДК старый...располагаю версией 4.3.0

kasa · Сообщение **kasa** » 04 сен 2008 10:57

Скачал СДК с сайта - все так же. Кстати, а где взять библиотеки типов для сервера сообщений (.tlb или .h файлы)?

vd · Сообщение vd » 04 сен 2008 11:35

Наш сервер сообщений основан на WCF, входящий в состав .NET. Для взаимодействия с сервером на другой машине это оказалось предпочтительнее, чем DCOM.

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

С WCF таких проблем нет - если с машиной есть связь через TCP или прочий сетевой протокол, то WCF работает.

kasa · Сообщение **kasa** » 04 сен 2008 11:50

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

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

Однако, в СДК-то описаны именно COM объекты? Или так оно и должно? Я просто с WCF пока не сталкивался...можете разъяснить вкратце, как мне это использовать в моей задаче?

Даниленко Сергей

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

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

Однако, в СДК-то описаны именно COM объекты? Или так оно и должно? Я просто с WCF пока не сталкивался...можете разъяснить вкратце, как мне это использовать в моей задаче?

Так оно и должно. Работать вы будете с COM-объектами. Но транспорт будет осуществляться серез WFC. Вы с ним работать напрямую (использовать) не будете.
Нужен DotNet 3.0 для работы WFC.

Мне не понятно, как оно попадет на другую машину. Или это реализовано внутри proxy/stub COM-сервера?
Тогда не понятно, зачем использовать сообщения, а не реализовать через механизм connection points?

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

kasa · Сообщение **kasa** » 04 сен 2008 22:16

Спасибо за оперативные ответы!
Почти все стало ясно, кроме того, где же таки взять библиотеки типов для сервера? Или, может быть, бинарные файлы?
В SDK я этого не нашел...

Даниленко Сергей

Более надежный способ такой (VC++):

//import SLMessageQueue2 1.0 Type Library
#import "libid:80418EB6-3E79-4F86-AB75-9549D4F38BD8" named_guids no_namespace raw_interfaces_only

Эту стрчку мы обычно располагаем в файле stdafx.h.

libid взято из OLE/COM object viewer

директивы импорта (named_guids no_namespace raw_interfaces_only) естественно можно выбрать свои.

Этот способ позволяет взять текущую версию автоматом. Естественно у вас должно быть установлено наше ПО (его можно ставить и на машину без платы).

kasa · Сообщение **kasa** » 07 сен 2008 16:27

Даниленко Сергей писал(а): Этот способ позволяет взять текущую версию автоматом. Естественно у вас должно быть установлено наше ПО (его можно ставить и на машину без платы).

С импортом библиотеки типов понятно все, однако, нет ли способа установить на машину только сервер сообщений?
Ведь это совсем не рационально, ставить весь пакет...

Даниленко Сергей

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

kasa · Сообщение **kasa** » 08 сен 2008 11:24

Ну, давайте хотя бы так поступим...

kasa · Сообщение **kasa** » 08 сен 2008 14:20

Кстати, не подскажете, как определить версию уже установленного ПО?

Даниленко Сергей

Все файлы ставятся сюда:
C:\Program Files\Common Files\SoftLab-Nsk

Всего файлов три:
1)SLMessageServer2.exe
2)SLMessageQueue2.dll
3)SLMessageRemote2.dll

Регистрация:
1)"C:\Program Files\Common Files\SoftLab-Nsk\SLMessageServer2.exe" /Service
2)regsvr32 "C:\Program Files\Common Files\SoftLab-Nsk\SLMessageQueue2.dll"
3)"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe" /codebase /tlb "C:\Program Files\Common Files\SoftLab-Nsk\SLMessageRemote2.dll"

!!!Должен быть установлен .Net Framework 3.0

Даниленко Сергей

Кстати, не подскажете, как определить версию уже установленного ПО?

Как это сделать "руками-глазами" описано здесь:
http://www.softlab-nsk.com/rus/forward/qna.html#a2_14

Или нужно программно?