Средства управления распределенными системами

Все возрастающее значение открытых систем привело к необходимости обеспечить возможность взаимодействия программных продуктов от различных производителей. Для обеспечения упорядоченности развития сетей и обеспечения взаимодействия процессов, выполняющихся в гетерогенных сетях, компанией IBM разработана концепция Open Blueprint , отвечающая всем требованиям, предъявляемым к открытым системам. Open Blueprint определяет структуру для управления распределенными системами и обеспечивает основу, на которой строятся, выполняются и управляются распределенные приложения в гетерогенных сетях. Она разработана на основе промышленных стандартов и позволяет удовлетворять требования заказчиков, предъявляемые к продуктам и решениям, которые соединяют различные аппаратные и программные платформы как корпорации IBM, так и других производителей. Следует отметить, что открытые распределенные вычисления, или технология клиент-сервер, в настоящее время являются основной моделью, определяющей развитие информационных технологий. Структура Open Blueprint дает возможность всем, кто имеет отношение к открытым распределенным средам, рассматривать систему как часть распределенной сети, а сеть, в свою очередь, трактовать как единую информационную структуру. Структура Open Blueprint представлена на рис. 4.1.(рис 4.1) Структура системы Open BlueprintОсновные ее <строительные блоки> - это менеджеры ресурсов, которые функционально сгруппированы в наборы сервисов:

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

Рассмотренные менеджеры ресурсов совсем не обязательно соответствуют каким-либо конкретным продуктам. Концепция Open Blueprint реализована в виде различных продуктов на различных системных и аппаратных платформах. Она только определяет атрибуты и свойства программного обеспечения, отражает функциональную модульность и стандартизирует различные интерфейсы.

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

Коммуникационные сервисы являются подсистемой распределенных системных сервисов, обеспечивающих механизм взаимодействия сетевых процессов. Они определяют три программных интерфейса:

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

CPI-C поддерживает взаимодействие между одновременно выполняющимися прикладными процессами, основанное на установке между ними логического соединения. Отсюда следует, что сетевой сеанс связи в этом случае имеет место только для взаимодействующих программ. Интерфейс CPI-C разработан, в первую очередь, для структурированного обмена информацией между программами. При этом взаимодействующие программы являются клиент-серверными приложениями, то есть приложениями, устанавливающими логическое соединение. Каждая программа при этом функционирует в своем (локальном) адресном пространстве. Программы, использующие интерфейс CPI-C, могут выполнять операции по обмену данными различного назначения. В рамках стандарта ISO диалоговая модель является базовой для обработки транзакций в спецификации протоколов OSI, базирующейся на архитектуре APPC SNA. Операционные системы используют протокол межпрограммного взаимодействия (APPC) для облегчения применения интерфейса CPI-C при разработке приложений. Указанный протокол в рамках систем MVS/ESA и OS-390 предлагает разработчикам набор встроенных функций для использования в клиент-серверных приложениях. Эти функции доступны из программ, написанных на языках высокого уровня, что избавляет от необходимости написания ассемблерных программ.

Вызов удаленных процедур (RPC) использует механизм вызова/возврата в/из процедуры для обеспечения взаимодействия между клиент/серверными приложениями. Клиентская (вызывающая) программа определяет местоположение сервера в сети (вызываемой процедуры), устанавливает необходимую связь и передает фактические параметры для выполнения требуемой процедуры. Вызывающая программа ждет завершения работы процедуры (выполнение этой операции синхронно!) и принимает результат. На сегодняшний день рабочие станции с приложениями, реализующими интерфейс RPC, работают как клиентские части в рамках системы OS-390 с использованием функций сервера сетевой файловой системы (NFS), поддерживаемых операционной системой. Кроме того, OS-390 поддерживает RPC в рамках сетевой вычислительной системы Apollo.

В рамках архитектуры OSF интерфейс RPC выбран в качестве базовой коммуникационной модели для распределенных вычислительных элементов (DCE). Интерфейс RPC в стандарте OSF/DCE поддерживается операционными системами OS-390 и MVS/ESA.

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

Сервис MQSeries IBM упрощает процесс межплатформенного взаимодействия, основанный на MQI. Этот сервис работает независимо от нижележащих сетевых протоколов. Использование MQSeries дает разработчикам возможность проектировать и реализовывать межплатформенные связи между приложениями быстрее и эффективнее, чем это может быть сделано с помощью традиционной техники программирования сетевых процессов. MQSeries поддерживает соответствующие коммуникационные протоколы и восстановление в случае возникновения аварийных ситуаций, обеспечивая корректную доставку сообщений. Информация может передаваться между приложениями, работающими в рамках System/390, серверов и персональных компьютеров. Наиболее целесообразным применение этого сервиса оказывается в тех случаях, когда взаимодействующие приложения характеризуются длительными промежутками работы без необходимости в установлении соединения, или промежутками периодического обслуживания. Такие случаи характерны для приложений, обрабатывающих транзакции с использованием IMS, CICS и TSO. Мосты для таких типов транзакций дают возможность пользователям различных систем иметь доступ к приложениям, работающим на мэйнфреймах, без перепрограммирования собственных интерфейсов. MQSeries поддерживает соединения как по протоколу TCP/IP, так и по протоколу SNA APPC. Поддерживаемые этим сервисом платформы включают в себя такие системы, как OS/2, MVS/ESA, OS/390, OS/400, VSE/ESA, VAX/VMS, UNIX, Sun Solaris и др.

Межпрограммный интерфейс взаимодействия CPI-C

Межпрограммный интерфейс взаимодействия CPI-C представляет собой программный интерфейс приложений, или API, который обеспечивает соединение (диалог) между программами в среде SNA . Интерфейс CPI-C обеспечивает возможность совместной работы прикладных программ, расположенных в географически удаленных узлах сети. Взаимодействуя друг с другом, такие программы могут решать различные общие задачи, например, осуществлять связь с удаленной базой данных, копировать удаленные файлы, обмениваться сообщениями электронной почты и т.д.

Для обеспечения такого взаимодействия в среде SNA необходимы различные элементы оборудования и программного обеспечения. На рис. 4.2 показаны эти элементы и связи между ними.

Каждая сетевая программа связана с логическим устройством LU, которое является для нее точкой доступа в сеть. С точки зрения прикладной программы LU выступает в качестве интерфейса, который она использует для установки связи с другой программой через сеть. Интерфейс CPI-C использует LU типа 6.2, которые поддерживают соединение между логическими устройствами. Прежде чем две программы смогут начать взаимодействие, их LU должны быть соединены между собой через сессию, которая является логической связью между двумя LU. Сессия устанавливается при включении особого режима, определяющего набор сетевых параметров, указывающих способ использования сессии. LU типа 6.2 могут обеспечить множественную сессию (две или более конкурирующих сессий с одним и тем же взаимодействующим LU).

Прикладные программы имеют доступ к интерфейсу CPI-C через вызовы CPI-C. Каждый вызов выполняет определенные действия, такие, как начало или завершение диалога, передача или прием данных, установка режимов и т.п. Программа, выполнившая вызов, рассматривается как локальная, другая программа считается удаленной. Вызовы CPI-C доступны для программ, написанных на различных языках программирования.

APPC (Advanced Program-to-Program Communications) - протокол, разработанный IBM и позволяющий приложениям работать на различных компьютерах и непосредственно обмениваться данными . Протокол APPC реализован как программное обеспечение, функционирующее в рамках различных операционных систем IBM и других типов. Он может являться или частью собственно ОС, или устанавливаться как отдельный программный пакет.

Протокол APPC выступает в качестве связующего звена между прикладными программами и сетью. Когда прикладная программа на локальной ЭВМ - источнике - передает информацию протоколу APPC, последний преобразует ее соответствующим образом и отправляет сетевому интерфейсу, например адаптеру локальной сети. Далее информация передается через сеть на ЭВМ - получатель, протокол APPC которой принимает ее от соответствующего сетевого адаптера. Далее протокол преобразует принятую информацию в исходный формат и передает соответствующему прикладному процессу. Очевидно, что связь между системами в этом случае выполняется на одном уровне (одноранговая связь). Для обращения к протоколу APPC из прикладных программ используются функции интерфейса прикладных программ (API) различного назначения. Примером таких API могут служить функции протокола передачи файлов APPC File Transfer Protocol (AFTP), обеспечивающие возможность обмена файлами между удаленными прикладными процессами. Для взаимодействия между прикладными процессами протокол APPC пользуется сессиями, установленными с помощью вызовов CPI-C, однако эти действия являются прозрачными для взаимодействующих процессов.

Вызов удаленных процедур

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, до передачи управления и данных через сеть . Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем отклика и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, это означает, что параметры RPC не должны содержать указателей на ячейки не стековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующее отличие RPC от локального вызова заключается в том, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах.

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

RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, вместо локальной процедуры используется другая ее версия, называемая клиентской заглушкой (stub). Подобно локальной процедуре, заглушка вызывается с использованием того же списка параметров, только в отличие от локальной процедуры она отправляет вызывающее сообщение на сервер. Вызывающее сообщение содержит параметры процедуры для процесса на сервере. Далее клиентский процесс ожидает от сервера ответного сообщения. Процесс на серверной стороне ожидает поступления вызывающего сообщения, дождавшись которого, извлекает параметры процедуры, выполняет необходимые вычисления и отправляет ответное сообщение клиенту. Далее процесс на серверной стороне ждет следующего вызывающего сообщения. Процесс на клиентской стороне получает ответное сообщение, извлекает из него результаты вычислений и продолжает выполнение. Взаимодействие программных компонентов при выполнении удаленного вызова процедуры показано на рис. 4.3.

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

Из вышеизложенного следует, что перед выполнением компиляции и связывания RPC-программы необходимо решить весьма важную предварительную задачу. Эта задача заключается в создании и компиляции файла определения интерфейсов, в котором находится описание клиент-серверных интерфейсов. Эти интерфейсы определяются на специальном языке определения интерфейсов (Interface Definition Language, IDL) и содержат набор <прототипов> для вызовов удаленных процедур со стороны клиента, которые реально должны быть выполнены на серверной стороне. После создания такого файла он компилируется специальным IDL-компилятором. Выходом этого компилятора является пара объектных файлов, один из которых относится к серверному модулю, а второй - к клиентскому. Они содержат коды клиентских и серверных заглушек, где все детали удаленного выполнения процедур, передачи данных и т.д. увязаны с библиотекой RPC времени выполнения. Эти файлы в дальнейшем связываются с результатом компиляции программ клиентской и серверной сторон. Кроме того, IDL-компилятор генерирует заголовочный файл для подключения его к исходным файлам клиента и сервера на этапе их компиляции. Заголовочный файл содержит все объявления, полученные из определений, имеющихся в IDL-файле. В частности, там находится глобальный уникальный идентификатор интерфейса (Global Unique Identifier, GUID), который используется во время выполнения для описания и привязки определенных в RPC-приложении интерфейсов. Вызовы удаленных процедур могут быть реализованы на любом языке программирования, поэтому язык определения интерфейсов является стандартным для всех сетевых платформ.

Интерфейс RPC не зависит от транспортных протоколов. В зависимости от ситуации, на транспортном уровне могут быть использованы или протокол TCP, или протокол UDP. В общем случае, взаимодействующие процессы пользуются механизмом сокетных соединений, что также показано на рис. 4.3.

Интерфейс очереди сообщений

Основными элементами системы MQSeries являются: сообщения, которые прикладные программы посылают друг другу; очереди для хранения сообщений; менеджеры очередей, управляющие очередями и обработкой сообщений; каналы передачи сообщений, связывающие менеджеры между собой. Прикладная программа передает свое сообщение серверу (менеджеру очередей), который записывает его в локальную очередь, а затем передает по сети другому менеджеру очередей, содержащему очередь-адресат. Программа-адресат обращается к своей очереди и получает доступ к сообщению. В результате система очередей сообщений предоставляет асинхронный метод взаимодействия программ, не требующий установки между ними прямой связи. При этом гарантируется, что передаваемое сообщение не будет потеряно или получено дважды. Процесс взаимодействия прикладных программ с помощью менеджера очередей представлен на рис. 4.4.

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

Сообщения (Message) MQSeries представляют собой структуру данных, состоящую из заголовка сообщения размером 324 байт (MQ Message Descriptor) и прикладных данных, в зависимости от платформы имеющих размер до 100 Мбайт.

Заголовок содержит контрольную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда передавать сообщение. Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. Для приложений, функционирующих под управлением разных ОС и оперирующих различными кодовыми страницами, поддерживаются методы преобразования данных. Очередь сообщений (Queue) является основным местом хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ - приложения могут получить доступ к очередям только через интерфейс MQI (Message Queue Interface). Менеджер очередей (Queue Manager) отвечает за управление очередями сообщений и прием вызовов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей MQSeries представляют собой совокупность очередей различных типов, каналов передачи сообщений между менеджерами, программ-мониторов и административных утилит. Прикладные программы взаимодействуют с системой MQSeries через интерфейс прикладного программирования MQI, который имеет единую структуру на всех платформах и основан на простой системе из десятка команд. Более подробно интерфейс MQI рассматривается в разделе 6.3.

Семантика общей транспортной среды

Взаимодействие сетевых процессов является <сердцем> инфраструктуры распределенных систем. В ранних поколениях вычислительных систем коммуникационные структуры в значительной степени влияли на сервисы и подсистемы, доступные прикладным программам. Современные распределенные высокоуровневые сервисы и менеджеры ресурсов, опирающиеся на клиент-серверную технологию, должны поддерживать различные операционные системы и широкий спектр сетевого оборудования. Отсюда следует, что менеджеры ресурсов нуждаются в сервисах, не зависящих от конкретных сетевых и канальных протоколов. Поэтому все современные распределенные системы обеспечивают четкое разделение между коммуникационными протоколами и сетевыми сервисами. Эта тенденция привела к структуре сетевого сервиса, определенной в Open Blueprint корпорации IBM. Она состоит из семантики общей транспортной среды (Common Transport Semantics), транспортных сервисов, подсетей, а также системы сигнализации и управления. В данном разделе рассматривается семантика (набор правил) общей транспортной среды (Common Transport Semantics, CTS) и ее реализация в виде коммуникационных серверов.

Common Transport Semantics изолирует сервисы вышестоящего уровня (CPI-C, RPC и MQI) от расположенных ниже транспортных сервисов. Это достигается обеспечением единой внешней структуры транспортных протоколов. Отсюда следует независимость сервисов высших уровней от транспортных протоколов, что, в свою очередь, ведет к возможности включения различных сетевых транспортных драйверов в общую реализацию этих сервисов. Кроме того, использование CTS делает возможной интеграцию сетей с различными протоколами через транспортные шлюзы, которые компенсируют различия в нижележащих сетевых транспортах. Это, в свою очередь, делает возможной совместную работу рабочих станций независимо от физической среды локальной сети LAN (маркерное кольцо, Ethernet) или транспортных протоколов (IPX, NetBIOS, SNA или TCP/IP).

В рамках Open Blueprint CTS тесно связана с мультипротокольной транспортной сетевой архитектурой (MPTN). MPTN определяет интерфейс как набор транспортных сервисов, объединяющих связи через множество сетевых протоколов. В дополнение к логическим связям через однородные сети она отделяет прикладные программы от сетей таким образом, что сообщения от приложений могут передаваться посредством любого протокола, объявленного в интерфейсе. Связь приложения и интерфейса осуществляется с помощью CTS. Таким образом, MPTN можно рассматривать как группу однопротокольных сетевых транспортов, каждый из которых имеет собственный протокол. Однако все они физически связаны и реализуют один и тот же протокол. Отсюда следует, что MPTN для пользователя имеет вид единой логической сети, имеющей единый протокол. Это обеспечивается двумя основными составляющими MPTN: Common Transport Semantics и шлюзами MPTN. На рис. 4.5 представлена логическая сеть MPTN, содержащая две однопротокольные сети, которые связаны через шлюз MPTN. Архитектура MPTN является открытой, и вообще говоря, исключает принудительные привязки сетевых протоколов и приложений к транспортным сервисам. Другими словами, API приложений и их сервисы могут взаимодействовать через протокол, отличающийся от предназначенного для них изначально. Приложения должны быть попарно согласованы, а именно, оба должны использовать один и тот же протокол.

Например, две программы, изначально использующие APPC и взаимодействующие через SNA, могут взаимодействовать через TCP/IP, две гнездовые программы, изначально использовавшие TCP/IP, могут взаимодействовать через SNA. Но APPC-приложение не может взаимодействовать с гнездовой программой ни через SNA, ни через TCP/IP.

Архитектура MPTN реализована как семейство продуктов AnyNet корпорации IBM. Семейство продуктов AnyNet дает возможность существующим приложениям без всяких модификаций взаимодействовать через сети с множеством сетевых транспортных протоколов. Использование функций этого семейства продуктов позволяет уменьшить количество транспортных протоколов в сетях, что, в свою очередь, ведет к снижению общей сложности распределенных систем.

Семейство продуктов AnyNet состоит из различных компонентов для использования в различных операционных системах IBM: AIX, MVS, OS/2, OS/400 и на платформах Windows. Так, например:

Семейство продуктов AnyNet реализует архитектуру MPTN, которая поддерживает сетевые соединения на основе смешанных протоколов и функции межсетевых соединений. Частью продуктов AnyNet, например, являются:

На рис. 4.6 показана связь двух прикладных программ с помощью функции APPC через TCP/IP. Взаимодействующие программы используют функции API независимого LU 6.2 для доступа друг к другу. На этом рисунке отсутствует шлюз, поэтому оба прикладных процесса связываются через IP-сеть.

Если сконфигурировать коммуникационный сервер как сетевой узел, то функция APPC через TCP/IP может выполняться в качестве шлюза. В этом случае возможна установка сессии и потока данных между сетями SNA и TCP/IP, как это показано на рис. 4.7. Следует отметить, что функция APPC через TCP/IP поддерживает два или более шлюзов между двумя сетями, а также два или более шлюзов, соединяющие три или более сетей.

Свойство мультипротокольности реализовано в виде коммуникационных серверов. Коммуникационные серверы работают на различных платформах: OS-390, OS/400, UNIX (Linux), Sun Solaris и др. Используя различные коммуникационные серверы, APPC-приложения взаимодействуют с рабочими станциями в сети TCP/IP, имеющими доступ к API APPC. Таким образом, APPC-приложение через протокол TCP/IP, может являться хостом по отношению к рабочей станции, рабочей станцией по отношению к рабочей станции или хостом по отношению к хосту. Кроме того, в коммуникационных серверах поддерживается интерфейс гнездовых соединений BSD (Berkley Software Distribution) через протокол SNA.

Примером такого сервера может служить коммуникационный сервер CS Linux. Этот сервер представляет собой коммуникационное программное обеспечение, функционирующее в среде операционной системы Linux. Коммуникационный сервер CS Linux связывает прикладные программы через сети SNA и TCP/IP. Он преобразует рабочую станцию, функционирующую под управлением операционной системы Linux, в узел сети SNA. Такое преобразование выполняется с помощью добавления к рабочей станции ресурсов и протоколов SNA, что позволяет ей взаимодействовать с другими рабочими станциями и хостами в сети SNA. На рис. 4.8 показаны возможные варианты использования коммуникационного сервера CS Linux.

В левой части рис. 4.8 CS Linux установлен на отдельной системе z800, что разгружает основную систему z/OS. В правой части этого рисунка показан вариант установки CS Linux в одном из разделов основной системы z/OS.

Коммуникационный сервер CS Linux обеспечивает выполнение следующих служб:

На уровне управления данными сервер CS Linux предоставляет различные возможности для установки параметров трафика, таких как скорость передачи, размер блоков данных, параметров безопасности и т. п. Коммуникационный сервер CS Linux поддерживает различные типы LU для различных классов прикладных программ. Так, для иерархических сетей это зависимые LU. Например, LU0 обеспечивает простейшее межпрограммное взаимодействие, LU2 поддерживает эмуляцию терминала серии IBM - 3270. Другие типы LU позволяют прикладным программам принимать участие в распределенных вычислениях или взаимодействовать с удаленными терминалами.

В сетях APPN поддерживаются и независимые LU типа 6.2, с помощью которых обеспечивается автономное сетевое управление и межпроцессные взаимодействия. Каждое из взаимодействующих приложений связывается со своим LU и устанавливает таким образом сессию Коммуникационный сервер CS Linux обеспечивает несколько сот таких сессий одновременно.

Для разработки прикладных программ в состав сервера включен программный интерфейс приложений (API) для различных типов LU, для распределенных процессов, сетевого управления и администрирования собственно сервера CS Linux. Кроме того, в состав API этого сервера входят функции, обеспечивающие его совместимость с аналогичными серверами других типов из семейства AnyNet, предназначенны для работы в иных операционных средах.

В контексте коммуникационных серверов последний может рассматриваться как интерфейс, дающий возможность транзакционным программам (ТР) взаимодействовать с поддерживающими их LU. Он состоит из библиотеки команд (также называемых функциями, вызовами или подпрограммами), из которой ТР выбирает все необходимое для создания запроса к LU на выполнение какого-либо действия. Таким действием, например, может быть передача данных (SEND_DATA). LU обрабатывает полученный запрос и строит поток данных в соответствии с требуемым протоколом, добавляет заголовок с указанием адреса назначения и передает данные партнерскому LU. Одним из наиболее мощных коммуникационных серверов является интерфейс CPI-C, подробно рассмотренный выше. CPI-C использует общий для всех систем IBM набор синтаксических правил, вследствие чего в настоящее является фактическим стандартом.

Другие возможности коммуникационного сервера CS Linux включают в себя функции поддержки интерфейса APPC, который также был подробно рассмотрен выше, функции поддержки интерфейса гнездовых соединений IBM, функции поддержки интерфейса распределенных вычислений и процессов, таких как DB/2 и т.п.