Межпроцессное взаимодействие

У меня есть два приложения: X и Y.
X - это основное приложение, и оно обрабатывает много файлов XML. Его история насчитывает более 10 лет, и для хранения, обработки и обработки этих XML-файлов использовалось полдюжины методов.
Y - это инструмент отладки, который я разрабатываю, который может обрабатывать и отображать файлы XML в более удобочитаемой форме. По сути, это просто набор таблиц стилей, которые будут определять формат XML, и если он распознает формат, он преобразует XML в HTML, который отображается в компоненте TWebBrowser.

Проблема:
Когда Y активен, Я хочу, чтобы X отправлял любой XML, который он переходит в Y для отображения. Но только когда Y работает! Если Y не работает, X просто ничего не сделает.
Обнаружение Y должно быть выполнено в любой момент и должно быть быстрым. Я рассматривал возможность использования связи TCP / IP, но задержка, вызванная отсутствием Y, слишком велика. Тем более, что иногда обрабатывается много XML. Та же проблема с именованными каналами и аналогичными сетевыми решениями. Мне нужно быстро определить, работает ли Y и доступен, и если да, быстро отправьте XML, а затем продолжите X.
Я также подумал о том, чтобы сделать Y приложением на основе COM или, возможно, добавить DLL на основе COM с событиями, которые позволят взаимодействие между процессами. Решение DLL было бы интересным, поскольку оно предоставило бы X метод для загрузки XML-файла, а затем отправило бы событие Y для обработки XML. Кажется, это лучший вариант , хотя мне также нужно будет проверить, зарегистрирована ли DLL или нет. Если нет, то X даже не сможет его вызвать!
Приложение X также будет использоваться клиентами, которые не получат Y или дополнительную DLL, поэтому в большинстве случаев DLL не будет зарегистрирована. (Как я уже сказал, он предназначен для помощи при отладке ...)

Но, может быть, есть другие варианты? TCP / IP слишком медленный, COM слишком сложный.


X и Y будут работать в одной системе. Или просто X будет в системе, а Y полностью отсутствует.

Об использовании файлов с отображением памяти ... Хотя это практично, мне нужно иметь в виду, что в большинстве случаев Y не будет работать, поэтому MMF будет тратить память. Данные XML могут иметь размер до 4 МБ в X, поэтому наличие нескольких блоков такого размера в памяти - это немного излишне. Его можно использовать для отправки статусных сообщений между X и Y, но память иногда является проблемой для приложения X. И хотя MMF может быть подключен к физическому файлу, я вообще стараюсь избегать записи каких-либо временных файлов.
Это хорошее решение, но, боюсь, недостаточно хорошее.

Думаю, нужно несколько дополнительных объяснений. Приложение X - это приложение, которое будет использоваться в течение нескольких часов, при этом пользователи будут выполнять множество действий, которые преобразуются в множество обрабатываемых XML-данных. Приложение X - это настольное приложение, которое взаимодействует с несколькими веб-приложениями (REST), веб-службами (SOAP) и другими приложениями, и большая часть этого осуществляется через XML.
Приложение Y предназначено только для того, чтобы заглядывать внутрь процессов, запущенных X. Обычно X работает 20 минут, и появляется Y. С этого момента X должен начать посылать XML в Y, пока Y снова не исчезнет или пока X не завершится. В большинстве случаев Y будет запускаться только для захвата небольшой части выполняемых задач, и, возможно, он даже запускается несколько раз. Но, возможно, я думаю обо всем в неправильном направлении. Может быть, X должен быть сервером с Y, зарегистрированным на нем ... Это не проблема, когда Y не может найти X. Но X, не находящий Y, не может привести к задержкам или другим проблемам ...