Перенос RPG в Java на IBM iSeries

Ответ 1

Моя компания также пытается перейти на Java из RPG.

• Мы не пытаемся использовать JRE на тонком клиенте, мы переходим к веб-приложениям, поставляемым через браузер. Это может повлечь за собой (в конечном итоге) замену наших старых POS-сканеров на некоторые из новых ПК.
• Мне сообщили (архитекторы компаний), что JVM на ОС iSeries имеет некоторые проблемы с производительностью. Я лично не знаю, каковы эти ограничения. В нашем случае миграция включала выделение ресурса AIX, который должен быть намного лучше - поговорите со своим представителем IBM о том, нужно ли просто приобрести лицензию ОС (я просто программирую на предмет, я не участвую в аппаратное обеспечение).
• См. ответ на вопрос 1. В более широком контексте, когда вы пытаетесь обновить браузер (или любой другой ресурс), обычно это обрабатывается с помощью корпоративных лицензий. Большинство из них будут иметь опции для принудительных удаленных обновлений.

Некоторые другие примечания:

• Вы должны иметь возможность перейти только к .NET, хотя вам может понадобиться другое оборудование/разделы для запуска среды. По крайней мере, вы можете поговорить с DB2. Единственное преимущество Java в том, что он будет работать на той же ОС/аппаратном обеспечении, что и база данных.
• Я видел приложение screencraper здесь (оно было в VB.NET, но я уверен, что пример применим). Скребок экрана выполнялся путем ввода/размещения символов в определенных положениях на экранах (эквивалент substring()). Это может быть просто API, который мы использовали - я думаю, что слышал о решениях, которые могли читать имена полей. Однако он также полагался на поток программы RPG для нее логики и в остальном не поддерживался.
• Большинство программ RPG, которые я видел и написал, как правило, являются нарушением MVC, а это означает, что вы не можете сделать ничего, кроме тестирования интеграции. История и архитектура самого языка (и некоторых разработчиков) предпочитают, чтобы все (доступ к экрану экрана) в одном файле. Это также сделает попытку обернуть RPG для удаленного доступа к невозможности. IF, вы должным образом разделили все на Сервисные программы, вы должны быть в состоянии их завернуть (как эквивалент вызова метода native, почти) аккуратно - к сожалению, я ничего не видел здесь, 't склонны полагаться на один или несколько трюков, которые не задерживаются для типичного использования в Интернете (например, используя файл в QTEMP для управления выполнением программы - сеанс на iSeries эффективно исчезает каждый раз, когда запрашивается новая страница..).
• Java как язык имеет тенденцию способствовать лучшему разделению кода (обратите внимание, что его можно неправильно использовать так же плохо), поскольку он не имеет достаточно истории RPG. В общем, может быть полезно подумать о Java как о языке, где все является сервисной программой, где все параметры передаются с VALUE set, OPTIONS(*nopass : *omit) запрещается, обычно рекомендуется CONST, и большинство параметров type DS (datastructure - это отдельный тип в RPG) и передается указателем. Параметры уровня модуля не одобряются, если они предпочитают инкапсулировать все либо в переданные структуры данных, либо сами процедуры сервисной программы. STATIC имеет несколько иное применение в Java, делая переменную global и недоступную внутри процедур.
• RPG довольно проста, чем Java, как правило, и OO-программирование - совершенно другая парадигма. Вот некоторые вещи, которые, вероятно, заставят разработчиков перейти на Java:
  • Массивы в RPG начинаются с 1. Массивы в Java начинаются с 0.
  • Java не имеет параметров "ouput", и все примитивные типы передаются по значению (скопировано). Это означает, что редактирование целого числа не будет отображаться в методах вызова.
  • Java не имеет упакованного/подписанного кодирования, и поэтому более интенсивно переводится в/из чисел/строк. Тип Date в Java также имеет некоторые серьезные проблемы (включая время, вид), и гораздо сложнее существенно изменить представление/символ.
  • Сложнее читать и записывать файлы на Java, даже при использовании SQL (и забывать об использовании собственного ввода-вывода напрямую с Java). Однако это может быть смягчено с помощью хорошей структуры.
  • В Java нет операторов ENDxx, все использует скобки ({}), чтобы указать начало/конец блоков.
  • Все в Java находится в freeformat, и нет никаких столбчатых спецификаций любого типа (хотя сигнатуры процедур все еще требуются). На длине линии нет жесткости, хотя по-прежнему рекомендуется ~ 80 символов. Инструменты (свободные, даже) лучше, периоды и в целом гораздо полезнее (хотя они могут привыкнуть к тем, кто подвергается воздействию SEU). Существуют также огромные бесплатные библиотеки, доступные для загрузки.
  • Знак = не является контекстно-зависимым в Java так, как он есть в RPG, он всегда используется для назначений. Используйте double-equals, == для сравнения значений в Java.
  • Объекты (datastructures) не могут быть осмысленно сопоставлены с == - вам часто понадобится реализовать метод под названием equals().
  • Строки не изменяются, их нельзя изменить. Все операции, выполняемые над строками (либо самим классом /datastructure, либо из внешних библиотек), возвращают новые ссылки. И да, строки считаются структурами данных, а не типами значений, поэтому вы не можете сравнивать их с ==.
  • Нет встроенных эквивалентов директив /copy предкомпилятора. Попытка реализовать их неправильно использует Java. Поскольку они обычно используются для обработки кода "шаблона" (определения переменных или общего кода), лучше справиться с этим в архитеку. Переменные (ALL D-specs, фактически) definitons будут обрабатываться операторами import или import static, тогда как варианты с обычным кодом обычно обрабатываются каркасом или определяют новый класс.

Я уверен, что есть много других вещей, дайте мне знать, если у вас есть другие вопросы.

Ответ 2

Распространение и управление толстым клиентом было бы абсолютным кошмаром.

Идеальное решение - это веб-приложение на базе Java, размещенное на iSeries. Рабочие станции получают доступ к вашим приложениям через веб-браузер, как и ASP.NET.

Я использовал Grails Framework для модернизации и создания новых приложений, и он отлично работает.

Ответ 3

Когда IBM заявляет, что вам следует перейти на Java/J2EE, вам, вероятно, следует перенести свои приложения в веб-приложения, например, в ваши веб-приложения asp.net. Вероятно, вы должны использовать функциональный интерфейс, например JSF или GWT.

Веб-приложениям не нужно беспокоиться о проблемах JRE, поскольку вам нужен только стандартный браузер.

Однако я не знаю RPG, и я не знаю предлагаемой стратегии миграции.

Ответ 4

Я разработчик, занимающийся модернизацией as400. Пока, из моего опыта, я могу дать вам свои идеи.

В дополнение к веб-сайтам на базе Java EE вы, вероятно, можете использовать веб-службы на основе jax-ws, которые предоставляют услуги для разных плоских экранов и сетки.

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