Lers Framework + Web API, интеграция с другими платформами

Web-API и Framework это безусловно + в разработке связки ЛЭРС Учет со сторонним ПО или веб-сервисами, но они жестко привязаны к идеологии платформы .NET. В данном
сдучае предлагаю дать разработчикам “карт бланш” в виде проепритарного С++ модуля/драйвера (Framework), что поможет реалиpовывать нативные проекты на таких языках как


C/C++
Java/Scala
Node.js
Perl
PHP
Go
Python и др

Что это дает?

  1. Отвязка от платформы .NET, Visual Studio и языка C# и сервера IIS (тоесть наличие Веб-интерфейса ЛЭРС Учет упраздняется)
  2. Более гибкий инструмент для разработки систем интеграций ЛЭРС Учет с другими система - ERP, Scada, Web-services и тд
  3. Применение современных методов/технологий при разработке ПО и сервисов

Почему именно C++?
Большинство из приведенных языков разработки и интерпретаров способны адресовать dll библиотеки, написанные на языке C++, и работать с картой их функций через import

Lers Framework сейчас практически полностью основан на архитектуре и возможностях .NET

“Переезд” на платформенную технологию будет стоить нам колоссальных трудозатрат, которые остановят развитие ЛЭРС УЧЁТ на несколько лет, и никогда не "окупятся.

К тому же, сейчас возникает не так много реальных задач по интеграции, с которыми нельзя справиться с помощью .NET.

Я вас понимаю, но скажем так я лично не владею возможностями .Net и не пишу на C# (и врядли стану), поэтому и задал такой вопрос.
Технически это выглядело бы просто Lers Framework (C#) → Lers Framework (C++), с той же картой функций API

PS: по моему в Visual Studio или вообще у Microsoft есть инструменты для перевода .Net/C++, могу ошибаться

PS2: к примеру нашел вот такую реализацию GitHub - AlexAlbala/Alter-Native: Source code translator: from high-level language to native language (C++)

Пример из жизни: http://localhost/Api.asmx
Зачем делать некий middleware скажем на языке Go (golang.com), дабы получать в json данные от Api сервиса ЛЭРС и уже обрабатывать в неком GUI, хотя это вполне нормальный вариант (только сам API очень ограничен). Зачем держать IIS и веб-интерфейс? Или же мы могли обойтись связкой Lers Учет ↔ Сервис на Go (Api-сервер) ← GUI

Интересно было знать ваше мнение как разработчика, Антон. Спасибо.

Вот именно, что Lers Framework это не просто карта функций. Это набор взаимодействующих объектов, коллекций элементов, события, асинхронные методы и сериализация, которая выполняется через .NET Reflection. Преобразование всего этого на C++ это не простая конвертация данных и типов. Это коренная переработка всей архитектуры. Причём не только Lers Framework, но и нашего веб-интерфейса, клиента и сервера.

На C++ можно написать подобную библиотеку. Это огромные трудозатраты. Даже если мы полностью остановим развитие ЛЭРС УЧЁТ и займёмся такой переработкой, на это уйдут месяцы и годы. Но даже такая платфоменная библиотека не будет взаимодействовать со всеми инструментами. Её можно будет использовать только из проектов C++ как набор lib-файлов и подключаемых h-заголовков.

Ближайшая технология, которая обеспечивает подобную совместимость - ActiveX. Lers Framework “вырос” именно из такой ActiveX библиотеки, которая называлась “Библиотека автоматизации”. Поддержка её в конце концов стала настолько трудоёмкой, что нам пришлось от неё отказаться.

В итоге, родилась концепция Lers Framework, который не просто поддерживается как отдельный продукт, но является ядром для разработки всей системы. Это сильно упростило его поддержку и дала мощный толчок в его развитии.

В итоге, от Lers Framework в текущем его виде мы отказаться не можем. Он является основой развития ЛЭРС УЧЁТ и неплохо решает большинство задач по интеграции с другими системами. А на развитие и поддержку в актуальном состоянии C++ или ActiveX библиотеки у нас сейчас просто не хватит ресурсов.

Более реалистичным кажется вариант ActiveX библиотеки, которая основана на Lers Framework и написана на .NET с помощью COM-Visible классов. Однако ограничения технологии COM-Visible рано или поздно заставят нас от неё отказаться, поскольку поддержка в актуальном состоянии и фреймворка и библиотеки - задача не самая простая.

В заключение, про интеграцию со SCADA. В большинстве случаев для этого достаточно технологии OPC (которая, кстати, базируется как раз на COM).

Уже существуют .NET-библиотеки для упрощения создания OPC-серверов, поэтому при необходимости мы сможем реализовать нужные для OPС-функции. Это будет далеко не вся функциональность нашего фреймворка, но для интеграции со скадами должно хватить.

Я вас услышал ,Антон. Большая просьба оперативно ответить на Рекомендации к Web-API. Спасибо.

Технология веб-сервисов сейчас очень популярна и поддерживается множеством языков программирования. В отличии от библиотеки c++ она более гибкая и универсальная. Конечно есть и свои минусы.

Мы начали развитие веб-сервиса доступа к данным, т.к. столкнулись с проблемой совместимости версий. Некоторым нашим клиентам требовалось выгружать данные из нескольких серверов ЛЭРС Учет разных версий. При таком сценарии ни LERS Framework, ни библиотека c++ не справится с задачей.

Я так понимаю, будь у нас такой сервис, он бы помог решить все ваши задачи?

У нас есть идеи по доработкам: переход на RESTful модель, использование JSON , доработка или изменение механизма аутентификации и авторизации. К сожалению, у нас пока нет ресурсов для реализации этих планов, поэтому пока ждем отзывы с предложениями и пожеланиями по развитию.

RESTful интерфейсы сейчас лежат в основе веб-технологичного Интернета, это факт! многие компании - разработчики и крупные поставщики ПО уже давно перевели свои внутренние сервисы на эту технологию. SOAP вами был выбран по причине .Net, но эта прослойка уже устарела и да сейчас принято использовать JSON или не-SQL хранилища. Я сам веду разработку нашего сервиса для обмена информацией из Lers с ПО ЭнергоСбыт в нашем регионе. В основе моей разработки заложен стык технологий: логика построена на Node.js, промежуточное хранилище на базе RethinkDB (SQL Server → RethinkDB, посредством новой разработки от Google - GraphQL), view -слой построен на базе фреймворка React.js, ну и ваш Lers Web-API является входной точкой для получения данных из Lers.

Будучи веб-разработчиком мне приходится иметь дело с rest и поэтому я поднял этот вопрос. Тут больше идет речь именно об интеграции Lers Учет с другими системами и вывод данных в форматы применимые в других системах, но не узко - базирующихся только на .Net (я не спец в этой области). но и веб-сервисы и т.д. Мог бы оказать в развитии этого вопроса. Спасибо.

Замечательно, но только в новых, отдельных темах.

energon, очень прошу, используйте для ответа кнопку “Ответ”. Если цитируете - удаляйте и цитаты все, что не относится к делу.