Именованный канал WCF IPC

Я пытался войти в курс дела на Именованных каналах на этой неделе. Задача, которую я пытаюсь решить с ними, состоит в том, что у меня есть существующий сервис окон, который действует как драйвер устройства, который направляет данные из внешнего устройства в базу данных. Теперь я должен изменить этот сервис и добавить дополнительный пользовательский фронтэнд (на той же машине, с помощью формы IPC), который может контролировать данные, поскольку это передает между устройством и DB, а также передайте некоторые команды обратно сервису.

Мои начальные идеи для IPC были или именованными каналами или файлами с отображенной памятью. До сих пор я работал через идею именованного канала с помощью Учебного руководства WCF Основное Межпроцессное взаимодействие. Моя идея состоит в том, чтобы настроить службу Windows с дополнительным потоком, который реализует Услуги WCF NamedPipe, и используйте это в качестве кабелепровода к внутренностям моего драйвера.

У меня есть работа примера кода, однако я не могу получить голову приблизительно 2 проблемы, что я надеюсь, что кто-то здесь может помочь мне с:

1. В учебном руководстве ServiceHost инстанцируют с typeof (StringReverser), а не путем ссылки на реальный класс. Таким образом, кажется, нет никакого механизма для Сервера для взаимодействия с самим сервисом (между хостом. Открытый () и хост. Близко () строки). Действительно ли возможно создать ссылку между и информацию о передаче между сервером и классом, который на самом деле реализует сервис? Если так, как?

2. Если я выполняю единственный экземпляр сервера и затем выполняю несколько экземпляр клиентов, кажется, что каждый клиент получает отдельный экземпляр класса обслуживания. Я пытался добавить некоторую информацию состояния к классу, реализовывая сервис, и это было только сохранено в экземпляре именованного канала. Это возможно связано с первым вопросом, но должно там так или иначе вынудить именованные каналы использовать тот же экземпляр класса, который реализует сервис?

3. Наконец, какие-либо мысли о MMF по сравнению с Именованными каналами?

Редактирование - О решении

Согласно ответу Tomasr решение находится в использовании корректного конструктора для предоставления конкретного singleton-класса, который реализует сервис (Конструктор ServiceHost (Объект, Uri [])). То, что я не ценил, в то время была его ссылка на обеспечение класса обслуживания, было ориентировано на многопотоковое исполнение. Наивно просто изменение конструктора вызвало катастрофический отказ в сервере, и которые в конечном счете приводят меня вниз путь понимания InstanceContextMode из этой записи в блоге Instancecontextmode И Concurrencymode. Установка корректного контекста приятно разрушила решение.