Могу ли я иметь кроссплатформенное кросс-технологическое решение?

Question

У нас есть старое приложение, которое имеет FORTRAN API, который вызывается из других приложений. Через некоторое время они создали оболочку (C) для API FORTRAN . Затем я создаю оболочку c ++ с небольшой обработкой данных для C API.

Так что я думаю, что это лучший способ создания API, который можно вызывать из любого языка программирования.

Теперь я планирую построить RPC-сервер из моего c ++ API. Тогда любой клиент, использующий любой язык программирования, может назвать его.

Я обнаружил, что XML-RPC хорош. Но для подключения требуется HTTP-сервер .

Проблема в том, что приложения, которые вызывают наш API, являются настольными приложениями. И я обнаружил, что XML-RPC не может манипулировать сложными объектами .

Является ли SOAP хорошим решением? Может ли сторона клиента быть легко реализована?

Так какое техническое решение лучше всего подходит для моей ситуации? Какую технологию мне использовать?

комментарий : У меня нет разрешения на изменение Fortran API и C API. И мне нужен API c ++, потому что я добавляю в него новые методы и совершенствую код, чтобы пользователь мог легко вызывать методы.

С наилучшими пожеланиями,

Answer 1

Лучший способ - оставить это в покое и просто использовать C API. практически все языки программирования могут напрямую вызывать C API , поэтому нет смысла создавать обертки, если модель программирования конкретного языка не имеет больше смысла другим способом.

Чтобы уточнить, что я имею в виду, посмотрите на GTK +. Это C API и может использоваться практически на любом языке. Оболочки существуют в объектно-ориентированных языках, которые обеспечивают подход чистого ООП к API GTK +, потому что это имеет смысл для этих языков, учитывая область API.

Имеет ли объективированный интерфейс смысл для вашего приложения? Если нет, то нет причин для создания оболочки C ++.

Что касается RPC, почему недостаточно простого интерфейса передачи сообщений с общей памятью?

Answer 2

Любой приличный язык имеет API сторонней функции. Просто вызовите функции Фортрана напрямую. Документация компилятора расскажет вам, как - вызов Fortran в разделяемой библиотеке очень похож на вызов C в разделяемой библиотеке, за исключением того, что разные компиляторы могут нормализовать имена функций в нижний регистр или нет или могут добавить подчеркивание. Некоторым FFI может потребоваться некоторый код-обертка C - например, Java - но многие могут просто взять имя функции и типы параметров и имя библиотеки для загрузки.

Если это не удастся, вы можете реализовать потоковый интерфейс для Fortran (чтение и запись в стандартный вывод) и просто перенаправить ввод и вывод данных - я сделал это, когда быстро перенес интерактивные приложения ISPF Fortran на ПК.

---

Поскольку вы хотите представить API C ++ и расширения, а не API Fortran, посмотрите на SWIG , который автоматизирует процесс для различных языков, если C ++ не слишком сложен ,

Answer 3

SOAP, XML-RPC и т. Д. Обычно используются для связи между компьютерами, это то, что вы хотите? Или все это работает только на одном компьютере?

Если это только на одном компьютере, просто придерживайтесь C API, большинство систем может использовать это

Если вы моделируете C API как службу стиля REST, то вы также можете предоставить службу HTTP для приложений, которые не могут использовать C API без, но имеют только одну систему для документирования