У меня есть два приложения: 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 может быть подключен к физическому файлу, я стараюсь вообще не писать никаких временных файлов. < br /> Это хорошее решение, но я боюсь, что оно недостаточно.
Некоторые дополнительные объяснения приведены в порядке, я думаю. Приложение X - это приложение, которое будет использоваться в течение нескольких часов, при этом пользователи выполняют множество действий, которые преобразуются во множество обрабатываемых XML-данных. Приложение X является настольным приложением, которое взаимодействует с несколькими веб-приложениями (REST), веб-службами (SOAP) и другими приложениями, и большинство из них - через XML.
Приложение Y предназначено только для просмотра процессов, запущенных X , В основном, X работает в течение 20 минут, а Y всплывает. С этого момента X должен начать посылать XML на Y, пока Y снова не исчезнет или пока X не завершится. В большинстве случаев Y просто запускается, чтобы захватить только небольшую часть запущенных задач, и, возможно, он даже запускается несколько раз. Но я могу думать обо всем в неправильном направлении. Возможно, X должен быть сервером, где Y регистрируется на нем ... Это не реальная проблема, когда Y не может найти X. Но X не находит Y не может привести к задержкам или другим проблемам ...