Существует два типа решений
Первое: попросите исходное клиентское приложение добавить параметр с адресом веб-службы A и использовать этот адрес для вызова службы.
Второе: передать более абстрактный идентификатор пользователя от клиента (на самом деле, есть большая вероятность, что у вас есть такое поле в сервисе). и использовать службу перевода для извлечения физического адреса, соответствующего этому идентификатору.
Чтобы разрешить такой перевод, настольное приложение, выполняющее роль сервера, при запуске должно «зарегистрироваться» в службе перевода.
Если вы используете ESB или другую инфраструктуру SOA (например, каталог службы, служба очереди сообщений), она будет включать большую часть функций, необходимых для построения службы перевода.
относительно фактического размещения услуги на клиентском компьютере.
самое простое решение - использовать процесс, отличный от реального приложения, и просто получить доступ к файлам или БД, которые использует приложение.
В этом случае вы можете использовать любую инфраструктуру, которая вам нравится, для развития сервиса.
более сложный сценарий, когда вам нужно фактическое приложение для предоставления услуги. в этом случае вам понадобится поток в приложении, который слушает запросы на обслуживание.
если вы используете WCF, см. Hosting Services о том, как разместить веб-службу в вашем приложении.
EDIT
некоторые дополнения, касающиеся вашего разъяснения.
Как я понимаю, настольное приложение предоставляет API C \ C ++, который доступен для внешних процессов на той же машине.
Вы можете написать веб-сервис, который будет использовать этот API. Поиск в Google "C ++ Web Services Windows" даст вам несколько советов по их реализации.
Еще одним хорошим вариантом является использование инфраструктуры обмена сообщениями. большинство провайдеров JMS предоставляют API на языках, отличных от Java, включая C ++.
Ваше приложение будет службой Windows C ++, которая слушает и отправляет сообщения вашему провайдеру JMS.