Веб-разработка Кобола / хостинг [закрытых] ресурсов

Пожалуйста, не используйте для этого COBOL. Любой, кому придется поддерживать сайт в будущем, поблагодарит вас за выбор более ... современного инструмента.

Я рекомендую вам использовать веб-фреймворк для написания интерфейса, например PHP, ASP.NET MVC и т. Д. Затем создайте API (или отдельный процесс с каким-либо интерфейсом, если требуется), который будет позволить этому инструменту взаимодействовать с вашей серверной частью COBOL. Это позволит вам использовать веб-фреймворк во внешнем интерфейсе - там, где он будет сиять - и в то же время позволит вам использовать значительные инвестиции вашей компании в COBOL.

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

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

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

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

У них также есть другой продукт "COBOL.Net", который предоставляет интерпретатор .NET IL для программ COBOL.

Поскольку этот продукт создан на платформе .NET, вы можете смешивать и сочетать его с C# и т.д.

Это позволяет вам получить лучшее из обоих миров. Вы сохраняете существующий COBOL back-end, но можете разрабатывать веб-приложение с помощью современных инструментов, например, ASP / MVC / Struts / JSP. И вы соединяете их вместе с помощью веб-службы.

Первоначальная реакция большинства людей на разработку веб-приложения на COBOL очень негативна!

В целом я согласен и рекомендую не использовать COBOL для интерфейсной веб-разработки просто , потому что есть другие инструменты, которые поставляются с большим количеством предварительно подготовленной поддержки для создания такого рода заявление. Поддержка обычно осуществляется через библиотечные надстройки и встроенные интерфейсы к веб-службам. Сам язык реализации менее важен.

Например, Ruby on Rails - это каркас приложения, основанный на модели MVC, использующий Ruby (язык) для «склеивания» всего этого. Изрядная часть ваших усилий по разработке испаряется , пока вы придерживаетесь фреймворка Rails. Однако сломайте структуру , и она вполне может сломать вас. Я считаю, что такие фреймворки, как Ruby on Rails , идеально подходят для новых разработок, когда вы контролируете все с нуля.

Ваша ситуация может несколько отличаться.Если я правильно понял, у вас есть база приложений COBOL и база данных mySQL, которые необходимо интегрировать в новое веб-приложение. Фреймворк Rails может быть, а может и не быть особенно полезным в этом контексте. Все зависит от того, как вы «встречаетесь посередине». Это довольно распространенная отраслевая практика - использовать надежные веб-инструменты для создания интерфейса веб-приложений с серверной частью на основе COBOL. Объединение этих двух элементов является довольно специфичной для платформы формой art .

Те же комментарии относятся к любой другой структуре веб-приложения и набору инструментов. Я просто использовал Ruby on Rails в качестве примера. Суть в том, что не многие люди (в том числе и я) задумывались о том, как работать с веб-приложением с помощью COBOL.

Несмотря на вышесказанное, я заметил, что вы используете openCobol в своем магазине. Это может сделать создание единственного решения на языке COBOL разумной перспективой. В отличие от многих реализаций COBOL, openCobol поставляется "готовым к работе в Интернете", а имеет независимый от базы данных абстрактный уровень , поэтому доступ к базе данных mySQL должен быть довольно безболезненным. Готовность к Интернету отчасти является следствием использования openCobol двоичного интерфейса приложений (ABI) C. C ABI должен значительно облегчить работу в смешанной языковой среде и сделать взаимодействие с CGI (Common Gateway Interface) довольно тривиальным; как видно из этого примера .

OpenCobol делает создание веб-приложений возможным, но практично ли это? Как отмечалось ранее, , если не существует документированной инфраструктуры веб-приложений, на которую можно было бы опираться, вы в конечном итоге многое из этого будете делать сами.Я думаю, что вы, возможно, уже пришли к такому выводу, когда публикуете свой вопрос. Насколько я могу судить, разработка такой структуры также возможна, но пока не существует. Если вы продолжите этот проект, возможно, вы могли бы внести свой вклад в разработку инфраструктуры веб-приложений для openCobol.

Я нашел ссылку "Cobol on Cogs" в принятом ответе немного несправедливым, вы задали серьезный вопрос и заслужили совершенно серьезный ответ. Этот тип упоминания, вероятно, отражает некоторую закрытость взглядов на COBOL (да, я готов и ожидаю голосов против).

Если вам НЕОБХОДИМО использовать Cobol, потому что вам нужно интегрироваться с некоторыми устаревшими API-интерфейсами COBOL, как насчет того, чтобы вы использовали Cobol для предоставления данных через какой-нибудь RESTful (или аналогичный) API. Затем напишите свое веб-приложение на чем-нибудь современном, например Django (что очень приятно). Затем веб-приложение Python может легко получить доступ к необходимым данным через RESTful API, который вы предоставляете в Cobol.

Это позволит вам использовать правильный инструмент для каждой работы: современную структуру веб-приложения для веб-приложения и некоторый код Cobol для предоставления данных, для которых у вас есть только Cobol API.