Мы поддерживаем систему с более чем миллионом строк кода COBOL. Есть ли у кого-то предложения о том, как перейти на графический интерфейс (возможно, на базе Windows), не теряя при этом всю бизнес-логику, написанную в COBOL? И да, некоторые бизнес-логики скрыты внутри текущего пользовательского интерфейса.Переход к графическому интерфейсу без потери бизнес-логики, написанной в COBOL
Возможно, это ваш лучший выбор. Написал screen scraper. Некоторые из основных систем ERP сделали это в течение многих лет при переходе с серверных приложений на 3-уровневые приложения. Один из них, с которыми я работал, имел множество интересных функций, таких как выпадающие списки для регулярно используемых полей, всплывающих окон и даже макросов на основе клиента, основанных на скребковых вводах.
Они были не очень хорошими, но хорошо работали для клиентов и следили за тем, чтобы приложения все еще работали надежно.
Существует много разных способов свести это вместе, но если вы вдумаетесь в это, вы, вероятно, можете использовать java или .net для создания приложения на основе рабочего стола и с небольшими дополнительными усилиями сделать веб-реализацию.
Если бы это было мне, что я хотел бы посмотреть на что-то вроде этого:
Это должно быть довольно легко обернуть COBOL с интерфейсом, который предоставляет функциональные возможности (если он еще не написано, что путь), а затем вызвать его из приложения .NET.
Нам потребовалось около 15 лет, чтобы выйти из нашего мэйнфрейма, потому что мы не делали ничего подобного.
Microfocus предоставляет инструмент под названием Enterprise Server, который позволяет COBOL взаимодействовать с веб-службами.
Если у вас есть программа COBOL A и другая программа COBOL B и A вызывает B через секцию интерфейса, инструмент позволяет вам открыть раздел интерфейса B в качестве веб-службы.
Для программы A вы затем создаете прокси-сервер клиента, и A теперь может вызывать B через веб-службу.
Конечно, поскольку у B теперь есть веб-служба, любой другой тип программы (командная строка, приложение Windows, Java, ASP и т. Д.) Теперь может также назвать это.
Используя этот подход, вы можете «откусить по краям», чтобы переместить графический интерфейс в современный подход на основе браузера, используя что-то вроде ASP, все еще используя бизнес-движок COBOL.
И как только у вас есть приличный набор веб-сервисов, они могут быть использованы для любой новой разработки, которая обеспечивает возможность уйти от COBOL в долгосрочной перспективе.
Вы можете использовать ESB, чтобы выявить устаревшие службы back-end, а затем закодировать свой графический интерфейс для вызова сервисов через ESB.
Затем вы можете начать замену устаревших сервисов на реализацию на своей новой платформе.
Графический интерфейс не обязательно должен учитывать переключение службы внутреннего обслуживания, если интерфейс к сервису не изменяется - незначительные изменения могут скрываться от графического интерфейса ESB.
Бизнес-логика, которая находится на уровне старого пользовательского интерфейса, должна быть реорганизована путем извлечения бизнес-логики и выставления ее, поскольку новые сервисы на новой платформе будут потребляться новым графическим интерфейсом через ESB.
Что касается выбора платформы для нового графического интерфейса, почему бы не рассмотреть веб-интерфейс пользователя, а не родную платформу Windows, то, по крайней мере, обновления для пользовательского интерфейса должны будут применяться только к веб-серверу, а не к с необходимостью развертывания изменений на каждой отдельной рабочей станции.