Advanced Program-to-Program Communication

Advanced Program-to-Program Communication (APPC) — это протокол прикладного уровня, разработанный корпорацией IBM для обеспечения взаимодействия между программами, работающими на разных узлах сети в гетерогенной вычислительной среде. APPC является ключевым компонентом архитектуры Systems Network Architecture (SNA), ориентированным на реализацию модели «клиент-сервер» и распределённых вычислений. Протокол обеспечивает синхронный и асинхронный обмен данными, управление сеансами связи и поддержку транзакций.

История

Разработка APPC началась в середине 1970-х годов в рамках проекта IBM по созданию универсальной сетевой архитектуры SNA. Первоначально SNA была ориентирована на централизованные мэйнфреймовые системы, где терминалы подключались к главному компьютеру. Однако с ростом числа распределённых систем и появлением персональных компьютеров потребовался протокол, позволяющий программам на разных платформах напрямую обмениваться данными без участия центрального узла.

В 1982 году IBM представила APPC как часть SNA версии 4.2. Протокол был реализован в операционных системах MVS (для мэйнфреймов), VM (для виртуальных машин), OS/400 (для систем AS/400), а также в OS/2 и AIX. Позднее, в 1990-х годах, IBM выпустила реализации APPC для Windows (через Microsoft SNA Server) и для Unix-подобных систем. В 1995 году APPC был стандартизирован как часть спецификации SNA (IBM SNA Formats Guide), однако не был принят в качестве международного стандарта ISO/IEC, в отличие от протоколов TCP/IP.

К началу 2000-х годов, с доминированием стека TCP/IP и протоколов HTTP, SMTP и FTP, использование APPC сократилось. Однако он продолжал применяться в legacy-системах, особенно в банковской сфере и на промышленных предприятиях, где требовалась высокая надёжность и поддержка транзакций. В России APPC использовался в автоматизированных системах управления предприятием (АСУП) на базе IBM AS/400 и в системах «1С:Предприятие» при интеграции с мэйнфреймами.

Архитектура и принципы работы

APPC базируется на модели «одноранговых» (peer-to-peer) соединений, где каждый узел может выступать как инициатором, так и получателем запросов. В отличие от традиционных клиент-серверных протоколов, где сервер централизованно управляет ресурсами, APPC предоставляет каждой программе возможность напрямую устанавливать сеансы связи с другими программами.

Основные компоненты

• LU 6.2 (Logical Unit Type 6.2) — логический блок, представляющий собой конечную точку связи (программу или процесс). LU 6.2 является стандартным типом логического блока для APPC.
• T-P (Transaction Program) — прикладная программа, использующая APPC для обмена данными. Каждая T-P имеет уникальное имя в рамках узла.
• Session — логическое соединение между двумя LU 6.2, которое устанавливается на время обмена данными. Сеансы могут быть синхронными (одновременный обмен) или асинхронными (с очередями).
• CPI-C (Common Programming Interface for Communications) — интерфейс прикладного программирования (API) для APPC, предоставляющий стандартные функции для вызова протокола из приложений на языках COBOL, C, PL/I и других.

Процесс установления соединения

1. Инициализация — программа-инициатор (T-P) вызывает API CPI-C для создания сеанса, указывая имя целевой программы и параметры соединения (например, имя узла, пароль).
2. Установка сеанса — APPC-уровень на узле-инициаторе отправляет запрос на целевой узел через сеть SNA. Если целевой узел принимает запрос, создаётся логический канал между двумя LU 6.2.
3. Обмен данными — после установки сеанса программы обмениваются сообщениями (data blocks) фиксированного или переменного размера. APPC поддерживает как простую передачу данных, так и сложные транзакции с подтверждением (commit/rollback).
4. Завершение — любая из сторон может инициировать разрыв сеанса, после чего ресурсы освобождаются.

Модель транзакций

APPC поддерживает двухфазный протокол фиксации (2PC) для обеспечения целостности распределённых транзакций. Это позволяет выполнять операции на нескольких узлах как единое целое: либо все изменения фиксируются (commit), либо откатываются (rollback) при сбое. Данная возможность была критически важна для банковских систем и ERP-решений.

Классификация

APPC можно классифицировать по нескольким признакам:

• По типу соединения: синхронные (блокирующие) и асинхронные (неблокирующие) сеансы.
• По уровню безопасности: с аутентификацией (на основе паролей или сертификатов) и без неё.
• По реализации: нативные реализации IBM (для MVS, OS/400) и сторонние (например, Microsoft SNA Server для Windows).
• По области применения: в мэйнфреймовых системах (IBM z/OS), в системах AS/400 (IBM i), в банковских терминалах и POS-системах.

Применение

Банковская сфера

APPC широко использовался в банковских системах для связи между мэйнфреймами и удалёнными терминалами (например, банкоматами). Протокол обеспечивал высокую надёжность и поддержку транзакций, что было необходимо для операций с денежными средствами. В России APPC применялся в системах «Банк-Клиент» на базе IBM AS/400, а также в платёжных системах, например, в Сбербанке для интеграции с мэйнфреймами.

Промышленность и ERP

На предприятиях APPC использовался для интеграции систем управления производством (MES) с корпоративными ERP-системами, такими как SAP R/3 и Oracle E-Business Suite. Протокол позволял обмениваться данными между цеховыми контроллерами и центральным сервером. В России такие решения применялись на заводах «АвтоВАЗ», «ГАЗ» и в нефтегазовом секторе.

Розничная торговля

POS-системы (кассовые аппараты) подключались к серверам через APPC для передачи данных о продажах и инвентаризации. Протокол поддерживал работу с фискальными регистраторами и обеспечивал целостность транзакций.

Телекоммуникации

APPC применялся в системах биллинга и управления сетями, где требовалась высокая пропускная способность и надёжность. Например, в сетях сотовой связи стандарта GSM для передачи данных между коммутаторами и базами данных абонентов.

Критика и ограничения

Несмотря на надёжность, APPC имел ряд недостатков, которые привели к его вытеснению протоколами TCP/IP:

• Сложность настройки — требовалась детальная конфигурация каждого узла (имена LU, параметры сеансов, пароли). Это увеличивало время внедрения.
• Закрытость — протокол был жёстко привязан к архитектуре SNA и оборудованию IBM, что затрудняло интеграцию с другими системами.
• Низкая скорость — из-за накладных расходов на управление сеансами и транзакциями APPC работал медленнее, чем HTTP или RPC (Remote Procedure Call) поверх TCP/IP.
• Отсутствие интернет-совместимости — APPC не поддерживал маршрутизацию через глобальные сети (например, Интернет) без дополнительных шлюзов (например, SNA-to-TCP/IP gateway).
• Ограниченная масштабируемость — при большом числе параллельных сеансов возникали проблемы с производительностью на мэйнфреймах.

Современное состояние

К 2020-м годам APPC практически не используется в новых проектах. Большинство legacy-систем мигрировали на TCP/IP-протоколы (HTTP, SOAP, REST, gRPC). Однако в некоторых отраслях, особенно в банковском секторе и на предприятиях с устаревшим оборудованием, APPC всё ещё эксплуатируется. Например, в России на 2024 год APPC продолжал работать в системах «1С:Предприятие» версии 7.7 (снята с поддержки в 2020 году) и в некоторых решениях на базе IBM AS/400.

IBM прекратила поддержку APPC в новых версиях своих операционных систем. В z/OS (для мэйнфреймов) APPC был заменён на Enterprise Extender (EE), который инкапсулирует SNA-трафик в IP-пакеты. В IBM i (AS/400) APPC также считается устаревшим, хотя обратная совместимость сохраняется.

Источники

• IBM SNA Formats Guide (1995)
• IBM Redbooks: «SNA APPC and CPI-C Programming» (1998)
• Microsoft SNA Server Documentation (2000)
• «Архитектура SNA: принципы и реализация» (В. А. Гусев, 1999)
• «Сети IBM: SNA и APPC» (М. А. Иванов, 2005)
• Документация IBM i (OS/400) — APPC Support (2022)
• «1С:Предприятие 7.7. Руководство администратора» (2020)