Файл: Архитектура информационных.pdf

85

namespace="urn:myDirectory" use="encoded"/>

Thesaurus WSDL File

Предполагается, что данное описание находится в файле Thesaurus, wsdl.
Имя сервиса SynonyraService определено в элементе service.
Далее определяются используемые пространства имен
(часть определений пропущена).
В элементах описаны используемые типы SOAP посланий. Используются два типа сообщений, которые называются

86 getSynonymRespons и getSynonymReques. Первое содержит поле synonym, а второе — поле word. Оба поля представляют собой строки символов.
Элемент называется Synonyms и выполняет только одну операцию getSynonym, которая получает входную переменную word. Входное послание имеет имя getSynonymRequest, а выходное — getSynonymResponse.
Элемент называется getSynonymSoapBinding. В нем указывается, что сервис работает в режиме запрос-ответ (использует грс-стиль), использует в качестве транспорта протокол HTTP, работает с SOAP- посланиями и выполняет операцию getSynonym. Затем в терминах SOAP повторяется описание операции getSynonym.
В элементе , который называется SynonymService, указывается местонахождение сервиса.
Элемент может содержать любые комментарии.
Поскольку в рассматриваемом примере не используются сложные типы, то элемент отсутствует.
WSDL-спецификация может быть получена автоматически из файла реализации Web-сервиса, например, из Java-файла или из описания интерфейса.
Имеется много разных систем поддержки работы с Web-сервисом. Одной из наиболее популярных является Apache extensible Interaction System (AXIS).
Можно выделить два альтернативных подхода к разработке Web- сервисов: подход по принципу «сверху-вниз» и подход «снизу- вверх».
В первом случае разработка начинается с разработки WSDL-опи- сания, которое используется для генерации скелетона и стаба, затем к ним добавляется бизнес-логика.
Во втором случае разработка начинается с создания кода для генерации
WSDL-описания.
Например, в рамках существующих инструментальных средств имеются утилиты для выполнения упомянутых выше преобразований [25, 13].
8. ОБЩИЕ ПРИНЦИПЫ ОРГАНИЗАЦИИ ВЗАИМОДЕЙСТВИЙ В
ИНФОРМАЦИОННЫХ СИСТЕМАХ

87
Системы обмена данными подразделяют на системы, использующие асинхронную и синхронную связь, а также на системы, работающие по принципу сохранной и несохранной связи [27].
При использовании асинхронной связи (asynchronous communication) отправитель после отправки сообщения немедленно продолжает работу, а сообщение сохраняется в локальном буфере передающего хоста или на ближайшем коммуникационном сервере. При использовании синхронной связи
(synchronous communication) работа отправителя блокируется до того момента, когда сообщение будет доставлено получателю, либо сохранено в локальном буфере принимающего хоста.
При использовании синхронной связи (synchronous communication) можно выделить три степени «жесткости»:
 отправитель может продолжать работу после того, как сообщение помещено во входной буфер получателя;
 работа отправителя блокируется до момента получения сообщения непосредственно пользователем, в этом случае от пользователя часто требуется подтвердить прием сообщения;
 работа отправителя блокируется до момента получения ответа.
При сохранной связи
(persistent communication) сообщение, предназначенное для отсылки, хранится в коммуникационной системе до тех пор, пока его не удастся передать получателю. Сообщение сохраняется на коммуникационном сервере до тех пор, пока его не удастся передать на следующий коммуникационный сервер.
Поэтому у приложения, отправляющего сообщение, нет необходимости после отправки сообщения продолжать работу. Приложение, принимающее сообщение, не обязательно должно находиться в рабочем состоянии во время отправки сообщения.
При использовании сохранной связи сообщения никогда не теряются и не пропадают.
Альтернативой использования механизмов сохранной связи является использование несохранные связи (transient communication. При применении

88 нерезидентной связи сообщение хранится в системе только в течение времени работы приложений, которые отправляют и принимают это сообщение.
Если коммуникационный сервер не имеет физической возможности передать сообщение следующему серверу или получателю, то сообщение уничтожается. Следует отметить, что все коммуникационные сервисы транспортного уровня поддерживают только нерезидентную связь.
На практике применяются различные комбинации этих типов взаимодействия.
Системы, основанные на вызове удаленных процедур или обращении к удаленным объектам, по большей части являются синхронными и реализуют несохранные связи. Хотя после того, как стало очевидно, что данные виды связи не всегда самые подходящие, были созданы средства для менее жестких форм нерезидентной синхронной связи, таких как асинхронные вызовы ИРС и отложенные синхронные операции.
Значительная часть существующих приложений представляет собой распределенные приложения, причем очень часто речь идет об интеграции уже существующих подсистем в единую ИС.
Типовыми проблемами, возникающими при создании распределенных
ИС и, в частности КИС, являются следующие:
 различия между приложениями;
 необходимость внесения изменений в код интегрируемых приложений;
 ограниченная скорость передачи данных;
 ненадежность сетевой инфраструктуры.
Отдельные приложения, входящие в состав распределенной системы, могут работать на разных аппаратных и программных платформах; написаны могут быть на разных языках программирования, использовать разные форматы данных и т.д.

89
Некоторые приложения на этапе разработки не были рассчитаны на работу в составе распределенных ИС, и их интеграция требует внесения изменений в исходный код.
Практически все интеграционные решения предполагают наличие каналов передачи данных устройствами. В отличие от процессов, выполняющихся в пределах одного хоста, в распределенных ИС данные передаются через маршрутизаторы, коммутаторы, общедоступные сети и спутниковые каналы связи, что может приводить к задержкам и рискам потери и искажения данных.
Обычно выделяют четыре базовых механизма интеграции приложений, входящих в состав распределенной ИС [27]:
 разделяемые файлы;
 разделяемая база данных;
 удаленный вызов процедуры и методов;
 обмен сообщениями.
Разделяемые файлы. Несколько приложений имеют доступ к одному и тому же файлу. Одно приложение создает файл, а другое считывает его.
Приложения должны согласовать имя файла, его расположение, формат, время записи и считывания, а также процедуру удаления.
Это один из самых старых подходов к интеграции приложений. Основная идея данного подхода состоит в том, что файл рассматривается как универсальный механизм обмена данными. Можно выделить два альтернативных подхода: распределенные файловые системы и системы, основанные на пересылке файлов.
При использовании распределенных файловых систем обмен осуществляется через общие файлы, которые включаются в состав файловых систем взаимодействующих приложений.
Альтернатива рассмотренному выше варианту взаимодействия приложений состоит в том, что файлы, в которых содержится информация, определяющая взаимодействие, пересылаются между хостами. По этому

90 принципу построена, например, система Unix-Unix Сору и ряд других систем.
При использовании данного подхода одним из наиболее важных решений является выбор общего формата файлов. В ранних приложениях наиболее распространенным стандартным форматом файлов являлся простой текстовый файл. В современных интеграционных решениях обычно используется XML- формат.
Основное достоинство рассматриваемого подхода — простота, поскольку единственными общедоступными интерфейсами приложений являются создаваемые этими приложениями файлы. В данном случае имеет место слабый вариант связи между приложениями. Кроме того, данный подход обусловливается отсутствием необходимости в привлечении дополнительных средств или пакетов для интеграции. Вместе с тем это приводит к возрастанию нагрузки, ложащейся на плечи разработчиков интеграционного решения.
Объединяемые приложения должны использовать общее соглашение об именовании и расположении файлов.
Один из наиболее существенных недостатков передачи файла заключается в сложности синхронизации процессов и сложности разработки кода.
Данный вариант взаимодействия может иметь смысл, если взаимодействие между приложениями носит эпизодический характер.
Разделяемая база данных. Основная идея данного подхода состоит в том, что данные хранятся в центральной базе данных, доступной для всех интегрируемых приложений. Общая база данных обеспечивает согласованность хранящейся в ней информации. Синхронизация доступа к данным реализуется посредством использования, например механизма транзакций.
Самый простой способ реализации общей базы данных состоит в использовании реляционной СУБД с поддержкой SQL. Язык запросов SQL поддерживается практически всеми платформами для разработки приложений, что позволяет не беспокоиться о различии в форматах файлов и избавляет от необходимости изучения новых языков программирования и новых технологий.

91
Все вопросы, связанные с интерпретацией данных, могут быть решены на этапе проектирования и реализации интеграционного решения.
С возрастанием числа обращений к общей базе данных она становится узким местом, что приводит к задержкам в работе приложений. Если обращения к разделяемой базе данных осуществляются через локальную и особенно глобальную сеть, то это лишь усугубляет ситуацию с задержками.
Подход к интеграции, основанный на использовании разделяемой базы данных, предполагает использование общей логической структуры данных.
Разделяемая база данных представляет собой неинкапсулирован- ную структуру. Изменения в приложении могут потребовать изменений в структуре базы данных, что, в свою очередь, скажется на других приложениях. Поэтому организации, использующие общую базу данных, обычно без энтузиазма относятся к необходимости ее изменения, что затруднит внедрение новых бизнес-решений.
Удаленный вызов процедуры и методов. С точки зрения интеграции приложений, удаленный вызов процедуры представляет собой применение принципов инкапсуляции данных. Если приложение хочет получить доступ к данным, которые поддерживаются другим приложением, то оно обращается к требуемым данным посредством вызова функции, т. е. каждое приложение самостоятельно обеспечивает целостность своих данных и может изменять их формат, не затрагивая при этом другие приложения.
Удаленный вызов процедуры и работа с удаленными объектами поддерживается множеством технологий, таких как RPC, Java RMI, CORBA,
DCOM, .NET Remoting. Несмотря на внешнюю схожесть, удаленный вызов процедуры и вызов локальной функции имеют принципиальные различия, способные оказать существенное влияние на интеграционное решение [15].
Следует отметить, что удаленный вызов процедуры характеризуется самой сильной степенью связывания приложений.
Обмен сообщениями. Идея обмена сообщениями состоит в том, что реализуется асинхронный механизм взаимодействия между приложениями,

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

9. ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ
Рассмотрим типы интеграционных задач. В широком смысле под термином «интеграция» можно понимать объединение ИТ-систем и отдельных приложений, входящих в их состав, интеграцию компаний (бизнеса) или людей.
В более узком смысле под интеграцией можно понимать объединение отдельных приложений в ИТ-систему, объединение отдельных ИТ-систем в более крупную систему и организацию взаимодействия между отдельными ИТ- системами по принципу В2В.
Интеграция приложений может принимать различные формы, прежде всего можно выделить внутреннюю и внешнюю интеграцию. Внутреннюю интеграцию обычно называют интеграцией корпоративных приложений
(Enterprise Application Integration, EAI), а внешнюю — интеграцией бизнес- бизнес (Business-to-Business Application Integration, B2B).
Исходя из последнего определения выделим четыре типовых подхода к решению задачи интеграции [15]:
 интеграция на уровне данных;
 бизнес-функции и бизнес-объекты;
 бизнес-процессы;
 порталы.
Конечно же приведенный выше список ни в коем случае не претендует на звание исчерпывающей классификации задач интеграции. Тем не менее он дает определенное представление о проектах в области интеграционных решений.

93
Некоторые интеграционные задачи объединяют в себе сразу несколько типов интеграции.
Интеграция на уровне данных. Данный подход называют также интеграцией, ориентированной на информацию
(Information-Oriented
Integration) [15].
Этот подход ориентирован, в первую очередь, на интеграцию данных, которые хранятся в базах данных и обычно имеет целью создание API, позволяющего программисту унифицированным образом работать с множеством БД, которые могут быть территориально разнесены и принадлежать разным производителям. В рамках данного подхода можно выделить, по крайней мере, три группы технологий:
 системы репликации баз данных;
 федеративные базы данных;
 использование API для доступа к стандартным ERP-системам.
В процессе функционирования многих ИТ-систем приложениям часто требуется доступ к одним и тем же данным.
Например, такая информация, как адрес проживания клиента, может использоваться как системой гарантийного обслуживания кли ентов, так и подразделениями, занимающимися рекламой. Некоторые из этих систем могут иметь собственные хранилища данных.
При изменении адреса клиента каждая из подсистем должна получить копию обновленной информации. Этого можно добиться с помощью такого типа интеграции, как репликация данных. Существует множество различных способов реализации репликации данных.
Функция поддержки репликаций может быть встроена в СУБД; нужные сведения можно экспортировать в файл для последующего импорта в другой системе, а также переслать внутри сообщений с помощью соответствующего промежуточного ПО.
Федеративные базы данных (Federated Database System) — это системы, которые позволяют прозрачным для пользователя образом