Размещение службы WCF в службе Windows - и начнем с чего-то
Я ищу в Интернете, но думаю, что у меня больше проблемы с пониманием, чем с технической... И, будучи интенсивным читателем SO, я знаю, что должен выставить все свои требования, а не задавать вопрос просто... так...
Разрабатываемый материал: Visual studio 2010 (..), C#, целевой фреймворк 3.5, профиль клиента.
Мое основное требование:
Вот мое требование: я хочу иметь загружаемое программное обеспечение, которое будет установлено на клиентских компьютерах. Эти инструменты будут периодически выполнять некоторые задачи [загружать некоторые данные о продажах (счета, заказы) из конкретной ERP-системы, с которой мы работаем.
Я не хочу, чтобы пользователь входил в систему, чтобы мой инструмент работал (если компьютер перезагрузится, я все равно хочу, чтобы мой инструмент запустился). Итак, здесь стандартная служба Windows кажется наилучшим выбором, так как интерфейсное приложение позволяет устанавливать некоторые параметры и видеть статус рабочего. На данный момент у меня есть служба Windows (C# 3.5) и интерфейсный инструмент. Обратите внимание, что в этот момент у меня все работало нормально. В методе OnStart моего сервиса я "инициирую" все свои вещи (готовлю папки, получаю параметры, подключаюсь к моему удаленному SQL Server в облаке, проверяю работоспособность системы, а затем жду задач с проверкой таймера для выполнения задач). Пока здесь все работает как положено.
Расширенные возможности взаимодействия между интерфейсным инструментом и моей службой Windows
Теперь я хочу поговорить / спросить что-то к моему сервису из моего Front-end инструмента. Я хочу спросить ("Сколько процессов вы запускаете сейчас", "Каково ваше текущее состояние таймера", "Какие таблицы вы используете в данный момент", "Прервать все ваши задачи" и т. Д...). Я попробовал немного "Пользовательскую команду", отправив пользовательскую команду в службу Windows, но она действительно ограничена: чтобы узнать ответы на вопрос "Какие таблицы вы сейчас загружаете", я попытался написать в Пользовательский журнал событий и извлечение его из моего Front-end-приложения, но я не нахожу это чистым, так как я, возможно, захочу получить быструю и повторно полученную обратную связь от моего инструмента (например, видя, как загружается ОДНА таблица, загружаются, обновляются каждые 5). secondes). Существует также запись в файл на жестком диске, но я могу захотеть, чтобы моя служба была размещена на другом компьютере, чем интерфейсный инструмент.
Путь WCF
Вариант 1 - Служба WCF является только коммуникатором, не более того.
Итак, как я обнаружил в интернете, я начал изучать вариант размещенной службы WCF. Итак, во-первых, я только добавил простую и аккуратную библиотеку службы WCF в основную службу Windows. Этот вспомогательный WCF-сервис будет отвечать только на сложные вопросы из внешнего интерфейса, а затем запрашивать ответы у своего создателя (основной службы Windows). Моя базовая настройка сработала -> при запуске моего Windows Servbice я запускаю все свои бизнес-процессы И запускаю (HostService) мою службу WCF для прослушивания. Но я не вижу способа полностью связать мою службу Windows с моей службой WCF (чтобы иметь доступ к основной информации о сложных службах). Статический метод? Передача основных классов "статусов" службе WCF, но как? ..
Вариант 2 - Сервис Wcf - это все.
Затем я попытался переместить ВСЕ свой код в службу WCF, сказав: "Хорошо, зачем иметь 2 сборки, если только ОДИН может сделать это?". Так что в начале моей основной службы Windows больше не было инициализации моего дела. Только запуск под-WCFServices. Все кажется хорошим на концептуальном уровне. Но как я могу сказать: "Хорошо, Служба WCF, Начни прислушиваться и начинать деловые дела"? Я не нахожу ничего о "запуске кода при запуске" службы WCF. В Интернете я вижу много "Службы WCF, в основном для" по вызову ". Но я хочу, чтобы служба WCF выполняла все мои вещи (загружала таблицу, загружала их в консоль и т. Д.) Через таймер" И быть в состоянии поговорить с интерфейсным инструментом. Должен ли я в основной службе Windows создать службу WCF и подключиться к ней немедленно, чтобы запросить конкретный открытый метод (через контракт на обслуживание)?
Итак, мой вопрос: 1 - имеет ли смысл моя архитектура? 2 - Имеет ли смысл хостинг WindowsService->WCFService для моих требований? 3 - Должен ли я переместить весь свой код в библиотеку службы WCF? или нет
большое спасибо!
Саймон
Редактировать:
Спасибо FerretallicA!
Честно говоря, я предпочитаю, чтобы все было хорошо разделено. Поэтому мне нравится ваша идея передать ссылку на мой класс моей службе WCF.
Просто для более полного материала, вот мой метод OnStart моих основных служб Windows:
Примечание: (большая часть кода взята из: Как: разместить службу WCF в управляемой службе Windows
protected override void OnStart(string[] args)
{
//The MyMainClass is global to my service.
MyMainClass = new DailyExtraction_MainClass();
//initiating the worker (setting the timer ticks, basic connexion,etc....)
MyMainClass.Initialiser_Robot_Extracteur();
//Write some log through my Worker
MyMainClass.MyLogExecution.WriteLog(" - End of OnStart()");
**//Here is the WCF Sub-service creation**
try
{
if (myWCFServiceHost != null)
{
myWCFServiceHost.Close();
}
// Create a ServiceHost for my class type and .
myWCFServiceHost = new ServiceHost(typeof(DailyExtractionUtils.CloudBI_Communicator));
// Open the ServiceHostBase to create listeners and start
// listening for messages.
myWCFServiceHost.Open();
}
catch (Exception ex)
{
MyMainClass.MyLogExecution.WriteLog(" - Error while trying to create the WCF Service");
}
}
Итак, я пытаюсь выяснить, где я должен передать ссылку на мой класс "MyMainClass".
ПРИМЕЧАНИЕ. Я только что повторно проверил вашу идею "как передать ссылку на вспомогательный wcf-сервис" и обнаружил, что: ТАК вопрос - вызов WCF, который ссылается на службу Windows. Я прочитаю это позже.
2 ответа
Является ли это жизнеспособным в ваших обстоятельствах или нет, будет зависеть от вашего дизайна сервиса, но два общих подхода, которые я бы рассмотрел для демонстрации сервиса от А до Б с общим дизайном, который вы представили:
- передать ссылку на основной экземпляр службы в WCF / службу мониторинга в конструкторе
- если вы используете что-то вроде Castle Windsor, зарегистрируйте ваш основной сервис как одноэлементный, чтобы сервис мониторинга мог обращаться к главному экземпляру сервиса из разных точек
Все в порядке
В этом нет необходимости, но в зависимости от характера основного сервиса может иметь смысл предоставлять функции мониторинга в соответствии с основными функциями.
[Я понимаю, что эта ветка старше, но я сам перечитал эти типы сессий вопросов и ответов для руководства; другие могут следовать, потому что у них есть похожие проблемы.]
Обычно в первоначальном дизайне платформы я бы предложил следующее правило: начать с конца. Другими словами, представьте, что вы реализуете это, и спросите, где вы собираетесь его разместить. Если вы размещаете его в облаке во многих случаях, часть, которая общается с конечным пользователем, может быть увеличена или уменьшена в количестве экземпляров в зависимости от потребности. В этом сценарии у вас может быть один или два экземпляра серверной части аналитики, которая на самом деле содержит данные. Если бы я думал, что он может быть позже размещен где-то в облаке, я бы предпочел разделительный подход в варианте 1 выше.
Кроме того, я думаю, что я хотел бы рассмотреть такие вещи, как точка задачи, где вы подключаетесь к самой системе ERP. Требуется ли для этой части простое соединение ODBC от Microsoft или стороннее соединение, такое как QODBC или подобное? Существует ли плата за каждую рабочую станцию для этого? Во-вторых, год за годом, если система ERP будет модернизирована, потребуется ли обновление части коммуникации? (Представьте себе, что затем необходимо обновить все клиентское программное обеспечение, чтобы не отставать.) По этим причинам я предпочитаю перенести эту часть на сервер где-нибудь локально или в облачном хранилище. Вы бы подключились с одним централизованным сервером к системе ERP, и она предоставила проанализированные данные другому программному обеспечению, которое вы сделали.
Таким образом, реализация, с которой, я думаю, я бы пошел, была бы службой WCF, работающей на локальном сервере, в сочетании с частью на стороне клиента, которая выполняется по команде конечного пользователя. Часть конечного пользователя не является службой, потому что она не должна быть.