Миграция в графический интерфейс без потери бизнес-логики, написанной на языке COBOL

Question

Мы поддерживаем систему, которая содержит более миллиона строк кода COBOL. Есть ли у кого-нибудь предложения о том, как перейти на GUI (возможно, на основе Windows), не теряя при этом всей бизнес-логики, написанной на языке COBOL? И да, некоторая бизнес-логика скрыта в текущем пользовательском интерфейсе.

Answer 1

Если бы это был я, я бы посмотрел на что-то вроде этого:

NetCobol для Windows

Должно быть довольно легко обернуть ваш COBOL интерфейсом, который предоставляет функциональность (если он еще не написан таким образом), а затем вызвать его из приложения .NET.

Нам потребовалось около 15 лет, чтобы выйти из нашего мэйнфрейма, потому что мы не делали что-то подобное.

Answer 2

Написание скребка экрана , вероятно, является лучшим выбором. Некоторые из основных систем ERP делали это годами во время перехода от серверных приложений к 3-уровневым приложениям. У одного, с которым я работал, было множество интересных функций, таких как выпадающие списки для регулярно используемых полей, всплывающие окна с датами и даже клиентские языки макросов, основанные на вводных данных.

Они были не очень хорошими, но хорошо работали для клиентов и обеспечивали надежную работу приложений.

Существует много разных способов собрать это воедино, но если вы задумаетесь над этим, вы, вероятно, могли бы использовать java или .net для создания приложения для настольного компьютера и с небольшими дополнительными усилиями сделать веб-реализацию.

Answer 3

Вы можете использовать ESB , чтобы предоставить доступ к унаследованным внутренним службам, а затем кодировать свой графический интерфейс для вызова служб через ESB.

Затем вы можете начать замену устаревших сервисов реализациями на новой платформе.
GUI не нужно знать о сокращении реализации внутренней службы, если интерфейс к службе не изменяется - незначительные изменения могут быть скрыты от GUI ESB.

Бизнес-логику, находящуюся на унаследованном уровне пользовательского интерфейса, необходимо реорганизовать, извлекая бизнес-логику и выставляя ее как новые сервисы на новой платформе, которые будут использоваться новым графическим интерфейсом через ESB.

Что касается выбора платформы для нового GUI, почему бы не рассмотреть веб-интерфейс, а не собственную платформу Windows, тогда по крайней мере обновления пользовательского интерфейса нужно будет только применить к веб-серверу, а не иметь развертывание изменений для каждой отдельной рабочей станции.

Answer 4

Микрофокус предоставляет инструмент Enterprise Server, который позволяет COBOL взаимодействовать с веб-сервисами.

Если у вас есть программа A на языке COBOL, а другая программа B и A на языке COBOL вызывает B через раздел интерфейса, инструмент позволяет вам представить раздел интерфейса B. как веб-сервис.

Для программы A вы затем создаете клиентский прокси, и теперь A может вызывать B через веб-сервис.

Конечно, поскольку у B теперь есть веб-служба, любой другой тип программы (командная строка, приложение Windows, Java, ASP и т. Д.) Теперь также может вызывать ее.

Используя этот подход, вы можете "откусить по краям", чтобы переместить графический интерфейс к современному подходу на основе браузера, использующему что-то вроде ASP, при этом используя бизнес-движок COBOL.

И если у вас есть приличный набор веб-сервисов, их можно использовать для любой новой разработки, которая дает возможность отойти от COBOL в долгосрочной перспективе.