1. Функциональное назначение программы, область ее применения, ее ограничения




Название1. Функциональное назначение программы, область ее применения, ее ограничения
страница1/8
Дата02.03.2013
Размер0.69 Mb.
ТипДокументы
  1   2   3   4   5   6   7   8


Федеральное агентство по образованию

Автономная некоммерческая организация науки и образования
«Институт компьютинга»


УТВЕРЖДАЮ

Директор АНО «Институт компьютинга»

_____________ /А.И. Миков/

«___»______________2008 г.


РЕКЛАМНО-ТЕХНИЧЕСКОЕ ОПИСАНИЕ


Система интеграции распределенных приложений Simple BizTalk Server (SBTServer)

.31569113.00003-02 99 01

Листов 76


Разработчики:

______________________/Лукиных И.А./

______________________/ Лядова Л.Н./

______________________/ Рыжков С.А./

______________________/ Рычков А.Ю./


08.08.2008>

1. Функциональное назначение программы,
область ее применения, ее ограничения


1.1. Назначение программы

Назначение программной системы Simple BizTalk Server (SBTServer) –интеграция распределенных приложений и баз данных на основе использования технологии BizTalk Server.

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

Сервер BizTalk – это программное обеспечение, способное считывать и обрабатывать документы BizTalk. Поскольку инфраструктура BizTalk базируется на XML и, как следствие, является самодокументированной, BizTalk-сервер должен уметь загружать документы XML и работать с их содержимым. Это первое требование. В спецификации документов и сообщений BizTalk Framework 2.0 базовые задачи выполняет BizTalk-совместимый сервер (BFC, BizTalk Framework Compatible).

Сервер BizTalk должен быть достаточно гибок для работы в быстро меняющейся бизнес-среде. Он должен обладать гибким интерфейсом, позволяющим сосуществовать и взаимодействовать с традиционными приложениями. Поскольку пользователи работают в разных системах, сервер должен обеспечивать взаимодействие с разными платформами и разными языками программирования [10].

Важнейшими функциями сервера BizTalk являются:

  • Надежная пересылка документов по любому протоколу.

Чтобы использовать документ BizTalk, его надо доставить получателю. Если последний – партнер по бизнесу, требуется система доставки документов. Наиболее распространены протоколы HTTP, FTP и упрощенный протокол передачи почтовых сообщений (SMTP).

  • Защита информации.

Спецификация BizTalk Framework 2.0 позволяет защитить документ BizTalk с помощью протоколов S/MIME и PKCS. Можно также применить протокол HTTPS, широко применяемый в Интернете и использующий асимметрическое шифрование.

  • Маршрутизация документов.

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

  • Документооборот.

Полученный документ BizTalk должен быть проанализирован, после чего приложение сможет выяснить его тип. Выяснив тип документа и его назначение, можно приступать к его обработке. Для всех входящих документов сервер BizTalk должен иметь несколько вариантов их обработки.

  • Синхронная и асинхронная связь.

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

  • Очередь сообщений.

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

  • Пакетный режим.

BizTalk-сервер должен поддерживать назначение параметров доставки документов BizTalk и их передачу в пакетном режиме в соответствии с требованиями партнера.

  • Отслеживание документов.

Сервер BizTalk должен иметь развитые возможности отслеживания выполнения транзакций, включая:

  • отслеживание отдельных документов и пакетов документов;

  • выявление неверно доставленных или не доставленных документов;

  • возможность опрашивать БД протоколирования по отдельным документам, по партнерам и по виду деятельности;

  • протоколирование времени выполнения всех действий с документами;

  • хранение данных, выбранных пользователем.

  • Управление взаимодействием с партнерами.

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

  • Масштабируемость.

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

  • Преобразование документов.

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

  • Встраивание модулей других производителей.

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

  • Прикладные интерфейсы.

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

  • Адаптация к изменениям.

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

  • Ориентация на нужды пользователей.

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

Сервер SBTServer – основа реализации систем документооборота, средств интеграции информационных систем бизнес-партнеров, баз данных в распределенной гетерогенной среде.

1.2. Область применения программы

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

Еще совсем недавно общепризнанного формата для организации документооборота не было (в отдельных областях (например, в электронной коммерции для организации взаимодействия бизнес-партнеров) использовались свои стандарты (EDI и т.п.), но они являются достаточно громоздкими). С появлением XML ситуация стала изменяться и в настоящее время именно он стал таким стандартом [26, 28, 36]. Многие современные системы теперь поддерживают этот формат и используют его для взаимодействия с внешним миром, учитывая универсальность этого формата.

Обычно мысли об интеграции нескольких информационных систем (ИС) разных организаций (или даже подсистем подразделений внутри одной организации) возникают уже после создания собственных ИС, причем по мере роста и развития корпоративной информационной инфраструктуры нередко оказывается, что отдельные ее подсистемы, выросшие из небольших и, как правило, разнородных приложений, «говорят на разных языках», основаны зачастую на разных СУБД, используют разные протоколы и разные форматы хранения информации [32]. Даже если исходно это было готовое решение, а не разработанное внутри компании, все равно высоки шансы, что программные продукты были куплены у разных фирм и потому слабо «понимают друг друга». Группа задач, решающих эти проблемы, объединяется под названием Enterprise Application Integration (EAI) – интеграция систем (приложений) предприятия [14, 23]. В конечном счете, интеграционное решение призвано снизить эксплуатационные расходы на поддержку программных систем, а также обеспечить доступность, целостность и непротиворечивость информации, жизненно важной для бизнеса компании [30].

Общие подходы к решению данной проблемы определяет инфраструктура BizTalk [52, 28, 43]. Однако программные продукты, основанные на этих технологиях (например, Microsoft BizTalk Server), требуют для установки значительных ресурсов.

На сегодняшний день очень много компаний предлагает свои услуги по интеграции приложений предприятия. Есть фирмы-лидеры в предоставлении подобных услуг. Их программные продукты обладают обширным спектром возможностей и, по заверениям компаний-разработчиков, обеспечивают уникальный и универсальный в своём роде подход. Но такие программные продукты разрабатываются под потребности мощных корпораций. Фирмы малого бизнеса не могут себе позволить закупить программные комплексы такого масштаба, да они и не нуждаются в полном функциональном наборе таких приложений. Тем не менее, надобность в интеграции возникает и у таких компаний. Хотелось бы иметь недорогой, достаточно простой в изучении программный продукт, который бы, тем не менее, содержал в себе необходимую функциональность по интеграции систем.

Именно такая задача решена при создании программной системы Simple BizTalk Server (SBTServer).

Основные требования, реализованные в программной системе:

  • Нетребовательность к программным и аппаратным ресурсам.

  • Универсальность представления связей между приложениями.

  • Расширяемость, настраиваемость на различные предметные области.

  • Мониторинг документов, ошибок системы, надежность обработки документа в системе.

  • Поддержка различных протоколов взаимодействия.

1.3. Ограничения использования программы

Программная система Simple BizTalk Server (SBTServer) позволяет настраиваться на различные программные платформы, работать под управлением различных операционных систем Microsoft, настраиваться на различные условия эксплуатации.

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

2. Техническое описание программы

2.1. Модель интеграции

На рис. 1 показана схема интеграции, которая описана в BizTalk Framework, и логические структуры, блоки с законченной функциональностью, которые будут необходимы для работы всей системы.

Благодаря этой инфраструктуре можно сразу ввести несколько понятий. В первую очередь понятие Документа. Именно Документ обрабатывается в системе и именно благодаря Документу осуществляется информационно-ориентированная интеграция. Всё, что попадает в систему для обработки, является Документом. Любая информация, даже если два Приложения обмениваются сообщениями через BFC-сервер, представляется в системе как Документ.

Далее можно ввести такое понятие, как Приложение. Приложение является отправителем документа, Приложение же является и получателем этого Документа.

Эти понятия – внешние по отношению к системе.

Итак, Приложение отправляет Документ BFC-серверу и он должен суметь его принять. Существующие приложения могут отправлять эти документы по совершенно различным протоколам. Таким образом, выделим такое понятие, как Адаптер: Приложение отправляет Документ такому Адаптеру, который работает по совместимому протоколу. Именно благодаря Адаптеру документ попадает внутрь сервера для его последующей обработки. Точно так же необходимо и обратное действие – обработанный Документ необходимо доставить Приложению-получателю. И в этом случае необходимо воспользоваться Адаптером, который передаст сообщение по тому протоколу, по которому общается Приложение-получатель.

Адаптеры являются граничным понятием между системой и внешним миром. Будем разделять Адаптеры, которые служат для получения, захвата Документов, назовем их Функциями Захвата, и Адаптеры, которые обеспечивают отправку Документа, будем называть их Функциями Отправки.

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



Рис. 1. Логические уровни модели

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

Выделим функционал по необходимой настройке Адаптера в отдельное понятие – Сервис Захвата. Сервис Захвата, как оболочка над Адаптером, содержит все необходимые настройки для корректной работы Адаптера и реализует передачу полученных Документов в Канал. Таким образом, несколько Сервисов Захвата могут передавать Документы в один Канал, используя один и тот же Адаптер.

Точно также необходимо реализовать возможность передачи сообщений нескольким Приложениям-получателям. В результате выделяется понятие Сервис Отправки. Документ из Канала может попасть в один или несколько Сервисов Отправки, который содержит всю необходимую настройку для Адаптера, чтобы осуществить передачу Документа Приложению.

Таким образом, имеем модель, представленную на рис. 2.



На описанную модель с легкостью накладывается модель Pub-Sub (Publish-and-Subscribe). В качестве Издателя и Подписчика выступает Приложение. Для того чтобы Приложение стало Издателем необходимо создать Сервис Захвата. Через этот Сервис Захвата Приложение будет помещать Информацию в Теме. Аналогом Информации в этой модели является Документ. А в качестве Темы можно рассматривать Канал. Для того чтобы стать Подписчиком определенной Темы необходимо создать Сервис Отправки для этого Приложения и соединить его с нужным Каналом. Таким образом, можно разослать один и тот же Документ нескольким Приложениям, что и является основой модели Pub-Sub.

Что касается модели P2P (Point-to-Point), то тут реализация немного сложнее. Нельзя напрямую сопоставить Очередь и Канал: если какой-то Документ попал в Канал и прошел в нем обработку, то он тиражируется по всем Сервисам Отправки. Таким образом, нарушается принцип этой модели в том, что получателем информации будет только одно из Приложений. Выхода два: организовать необходимую функциональность внутри системы или предоставить ее реализацию вне системы. В первом случае можно надстроить бизнес-процесс, который бы позволял управлять ситуацией и определять, кто окажется получателем на данном этапе. Во втором случае можно использовать понятие очереди сообщений Microsoft (Microsoft Message Queue, MSMQ). Итак, можно создать Сервис Отправки, который будет отправлять Документ в определенную Очередь сообщений, тогда Получатель должен опросить эту Очередь и забрать из нее информацию. Либо наоборот, какое-то Приложение отправляет информацию в эту Очередь, а посредствам Сервиса Захвата можно опрашивать эту Очередь и получать оттуда Документы для последующей обработки в сервере интеграции. Для этой цели необходимо реализовать Адаптеры для взаимосвязи с MSMQ.

Введем в модель понятие Очереди документов. На рис. 2 показан пример идеальной работы сервера интеграции. Документ прошел все стадии обработки без ошибок: был получен из вне через Сервис Захвата, прошел проверки внутри Канала, при необходимости был переконвертирован в другой формат и благополучно отправлен через Сервис Отправки. Назовем эти стадии обработки Рабочей очередью. Если на каком-то из этапов обработки Документа происходит ошибка, Документ необходимо сохранить в системе и дать возможность проанализировать ошибку, которая не позволила продолжить обработку. Для этого введем понятие Очереди приостановленных документов. Наконец, выделим среди ошибок предполагаемые помехи и времменую недоступность транспортной среды во время отправки Документов. Подобные ошибки необходимо обязательно фиксировать в системе, но переводить Документ из-за временых помех из Рабочей очереди в Очередь приостановленных документов – значит создавать дополнительную нагрузку на администратора сервера и вероятно задержать отправку документов. Для того, чтобы минимизировать подобный риск, введем понятие Очереди повторов отправки, что позволит прежде, чем перевести Документ в Очередь приостановленных документов, предпринять несколько попыток его отправки.

После введения понития Очереди приостановленных документов появилась необходимость введения понития Ошибки. Ошибка – это тоже объект системы со своим набором атрибутов. Местом фиксации ошибок служит Журнал ошибок. Именно на обеъекты Журнала ошибок должны сохранять ссылку элементы Очереди приостановленных документов. Неотъемлемой частью любой ИС является также Журнал событий, необходимый для мониторинга системы и проверки её работоспособности.

  1   2   3   4   5   6   7   8

Похожие:

1. Функциональное назначение программы, область ее применения, ее ограничения icon1. Функциональное назначение программы, область ее применения, ее ограничения
Комплекс программ предназначен для реализации порталов на основе case-технологии metas
1. Функциональное назначение программы, область ее применения, ее ограничения icon1. Функциональное назначение программы, область применения, ее ограничения
Интернетом, ярко выраженных «визуалов», нацеленных на немедленный результат. Обучение их предъявляет особые требования к компьютерной...
1. Функциональное назначение программы, область ее применения, ее ограничения icon1. Описание актуальностей, целей и задач разрабатываемого по, его назначение и область применения
Описание актуальностей, целей и задач разрабатываемого по, его назначение и область применения
1. Функциональное назначение программы, область ее применения, ее ограничения icon1 Назначение и область применения настоящих Правил, классификация трубопроводов
Утвердить Правила устройства и безопасной эксплуатации трубопроводов пара и горячей воды
1. Функциональное назначение программы, область ее применения, ее ограничения iconПоложение о планировании и организации учебного процесса 1 назначение и область применения
Гоувпо «Оренбургский государственный институт менеджмента» (далее Институт) в системе высшего профессионального образования
1. Функциональное назначение программы, область ее применения, ее ограничения iconНазначение и область применения
Электропечь индукционная плавильная тигельная типа ист-0,4/0,32 ёмкостью 0,4 т предназначена для индукционной плавки и перегрева...
1. Функциональное назначение программы, область ее применения, ее ограничения iconФильтрующие противогазы
Менения. Условия применения дополнительных патронов к фильтрующим противогазам. Камеры защитные, их назначение, устройство и порядок...
1. Функциональное назначение программы, область ее применения, ее ограничения icon*Область применения
Изменением n 1, утвержденным распоряжением первого заместителя Премьера Правительства Москвы от 3 августа 1999 г. N 592-рзп, в раздел...
1. Функциональное назначение программы, область ее применения, ее ограничения icon1. 1 Назначение
В настоящем разделе описывается назначение, область действия и структура документа. Приводится список определений, сокращений и аббревиатур...
1. Функциональное назначение программы, область ее применения, ее ограничения iconДекларация пожарной безопасности
Указывается организационно-правовая форма юридического лица, функциональное назначение, полное и сокращенное наименование
Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница