Я рассматриваю только следующее для таких случаев, как ваш, где совместимость с унаследованным кодом полезна или необходима, а другие возможности исчерпаны.Это не элегантный подход, но он может быть полезен в особых случаях.
Протокол XDBC (который использует XCC) изначально поддерживается на тех же серверах приложений и портах, которыеREST API выставлен.Вы можете увидеть это на порту 8000 при установке по умолчанию.Сервер буквально не может отличить «приложение REST» и «приложение XCC», кроме как по URI, запрошенному в запросе (и в некоторых случаях дополнительным заголовкам, таким как файлы cookie).REST и XDBC основаны на HTTP и на уровне HTTP очень похожи в той степени, в которой они могут использовать одни и те же порты и конфигурации.XDBC «проходит» через обработку REST через XML Rewriter.XDBC использует / eval и / invoke, тогда как REST использует / v1 / eval и / vi / invoke.Если вы посмотрите на файл rewriter.xml по умолчанию для порта 8000, вы увидите, как выполняется маршрутизация.Хотя протокол XDBC официально не публикуется, его «сложно спроектировать», взглянув на код XCC (общедоступный источник Java) и программу переписывания.Например, нетрудно построить URL-адрес и данные полезной нагрузки для выполнения базового eval или вызова call.Вы должны быть в состоянии точно реплицировать существующее поведение клиента XCC.NET, используя конечные точки / eval и / invoke (ищите атрибут xdbc, установленный в rewriter.xml, это заставляет обработку запросов использовать чистый протокол XDBC и поведение.
Другая альтернатива, если вы не можете решить проблему с внешними переменными, - это написать новый API-интерфейс REST Friendly, который затем xdmp: invoke () в устаревшей APIS передает соответствующие пространства имен.полностью отдельную базу данных модулей, а затем точно копировать URI модулей с новым кодом. Если вам не нужно поддерживать сосуществующие версии, измените старый код, чтобы удалить пространства имен из параметров или назначить псевдонимы локальных переменных.