РЕШЕНИЯ
В последние полтора десятилетия системная интеграция прошла эволюционный путь от чисто технической дисциплины, обеспечивающей сопряжение изначально несовместимых аппаратных и программных средств передачи, обработки и распределения информации, в сторону интеграции коммерческой или государственной деятельности, которая осуществляется в рамках управленческого и ИТ-консалтинга. Широкий масштаб использования информационных технологий в коммерческих и государственных организациях хотя и носил в первое время островной характер, но тем не менее, позволил говорить об электронизации управления бизнесом и госуправления в целом. В результате появились термины “электронный бизнес” (э-бизнес) и “электронное правительство” (э-правительство).
Пространство взаимодействия субъектов общества
В табл. 1 приведены виды и система обозначения взаимодействий между субъектами общества - государственными органами, коммерческими компаниями (бизнесом) и гражданами, а также примеры содержания этих взаимодействий.
Таблица 1. Пространство взаимодействия субъектов общества
В Российской Федерации в силу ее административно-территориального устройства могут иметь место информационные взаимодействия с госорганами, показанные на рис. 1:
- правительство (федеральное, окружное, региональное, муниципальное) с бизнесом;
- правительство (федеральное, окружное, региональное, муниципальное) с гражданами.
Рис. 1. Многообразие взаимодействий граждан и бизнеса
с правительствами разных уровней РФ
В свою очередь представители бизнеса могут взаимодействовать с другими представителями бизнеса, граждане с гражданами и т. д. Стоит также обратить внимание на возможность взаимодействия “через голову”, т. е. не соответствующего непосредственной субординации. Подобные взаимодействия могут возникать, например, когда вышестоящий орган, не удовлетворенный работой нижестоящего, вынужден обращаться за нужной информацией непосредственно к ее владельцам, “через голову”. В этом случае обращение минует несколько уровней административного деления.
Интернет сделал мир полносвязанным, что привело к существенному упрощению и удешевлению ведения коммерческой и государственной деятельности в глобальном масштабе. Это обострило проблему взаимодействия удаленных информационных систем (ИС), которые создавались без учета такой необходимости. Логистические цепочки автоматизированных бизнес-процессов вышли за пределы отдельных предприятий и организаций, охватив географически распределенные корпорации, а затем и весь мир.
Развитие э-бизнеса является логическим продолжением предшествующей стадии автоматизации предприятий, воплощенной в ERP-системах. Эти последние действительно были направлены на автоматизацию внутренней среды предприятия. Следующим шагом должна была стать автоматизация взаимодействия с внешней средой. Именно для решения данной задачи и предназначены системы э-бизнеса, основанные на глобальной системе коммуникаций, которой является Интернет. Так что появление и развитие э-бизнеса является, по сути, исторически закономерным и естественным процессом.
На дальнейшее развитие э-бизнеса будут влиять следующие стратегические факторы:
- глобализация деятельности предприятий;
- персонализация продуктов и услуг;
- возрастание роли обслуживания клиента;
- ужесточение конкуренции;
- развитие технологий;
- изменение подходов к организации и ведению бизнеса.
Все эти факторы приводят к большой динамике во взаимосвязи бизнесов в диапазоне от их тотального слияния (поглощения одного бизнеса другим) до разделения. В промежутке находятся образование из бизнесов логистических цепочек типа “потребитель - поставщик” и соединение их ИС при совместном создании продуктов либо объединение островов автоматизации внутри одной компании или ее удаленных подразделений.
Для объединения в рамках одной модели бизнеса как деятельности с его информационными технологиями, когда последние поддерживают достижение бизнес-целей, была придумана модель под названием “архитектура предприятия” (Enterprise Architecture), которая приведена в табл. 2. В равной мере эта модель применима и для госорганизаций (например, американская модель архитектуры федерального предприятия, см. PC Week/RE, N 28/2005, с. 27 и PC Week/RE, N 31/2005, с. 26, табл. 2).
Таблица 2. Архитектура предприятия
По этой модели легко определяются возможные уровни интеграции бизнесов (и, добавим, ведомств):
- полное слияние (интеграция) бизнесов путем использования единого набора показателей деятельности - подразумевает полную интеграцию на нижележащих уровнях;
- соединение бизнесов в логистическую цепочку путем интеграции их бизнес-процессов - подразумевает полную интеграцию на нижележащих уровнях;
- оказание услуг друг другу путем интеграции на уровне сервисов - подразумевает полную интеграцию на нижележащих уровнях;
- интеграция информационных систем компании на самых нижних уровнях данных и технических средств.
В результате можно предложить базовую модель интеграции бизнесов и ведомств с помощью некой среды электронного взаимодействия (рис. 2).
Рис. 2. Базовая модель интеграции бизнесов и ведомств (источник: [])
Интеграционная платформа для интероперабельности
Сейчас на западном рынке превалируют следующие названия для технологий объединения (интеграции) ИС, которые создавались не для того, чтобы соединяться с другими системами:
- интеграционная технология, или интегрирующая технология, или технология интегрирования (Integration Technology; автор - IBM) - по сути, это всем известная интеграция систем;
- интеграция корпоративных приложений, или решение новых задач на основе существующих приложений в удаленных машинах (Enterprise Application Integration; EIA, InterSystems и др.);
- интеграция бизнеса (Business Integration: Oracle), только одна российская компания применила этот термин в своем названии (Тops BI).
Последний термин более точно отражает предметное назначение технологии объединения не систем, а определенных участков бизнеса (или деятельности для госорганов и муниципалитетов), автоматизированных с помощью ИС. Тогда разговор об интеграции ИС начинается с постановки бизнес-задачи (что получит от интеграции бизнес, ведомство), а заканчивается собственно технологиями интеграции.
Интеграционные технологии одинаково применимы как в бизнесе, так и в государственном и муниципальном управлении. В первом случае речь идет, как сказано выше, о построении сквозных логистических цепочек предприятия из островов автоматизации (маркетинг, предложение товаров клиентам, заключение договоров с клиентами, поставка товаров клиентам и обслуживание товаров на площадках клиентов), а во втором - о взаимодействии госорганов друг с другом в ходе предоставления электронных услуг гражданам и бизнесу. Взаимосвязанный набор программно-аппаратных средств, реализующих интеграционную технологию, и представляющий собой как раз среду электронного взаимодействия, будем называть интеграционной платформой.
Желание сэкономить на затратах при внедрении ИТ в госорганах привело к понятию интероперабельности. Интероперабельность информационных систем одного или разных ведомств определяется как их способность передавать и использовать информацию унифицированным и эффективным способом. Модель интероперабельности (Interoperability Framework) - это набор регламентов, стандартов и руководств, определяющих согласованные ведомствами способы ведения дел друг с другом и адаптируемых по мере изменений в технологиях, стандартах и потребностях ведомств.
В результате модель общенациональной распределенной суперИС, обеспечивающей взаимодействие граждан и бизнеса с государством, может быть представлена в виде, показанном на рис. 3.
Рис. 3. Модель общенациональной распределенной суперИС
Эта модель имеет три уровня (сверху вниз):
1) каналы доступа к правительственной информации;
2) интеграционная платформа;
3) ведомства центрального, региональных и муниципальных правительств (ОМСУ - органы муниципального самоуправления).
Клиенты государственных услуг (граждане и бизнесы) входят в ИС ведомств и муниципалитетов через специальные входные точки, предметные правительственные порталы и порталы самих клиентов. Для подключения к этим точкам входа и порталам клиенты используют Интернет, центры обработки телефонных вызовов, информационные киоски и другие средства доступа.
Буквально в ноябре - декабре 2005 г. в выступлениях руководителя Мининформсвязи (Б. Антонюка о мультисервисной сети связи органов государственной власти) и Росинформтехнологий (В. Матюхина об инфраструктуре электронного правительства) мы услышали о желании этих ведомств создать нечто подобное общенациональной распределенной суперИС, представленной на рис. 3. Идея, конечно, не нова и восходит к упомянутой в тексте ФЦП “Электронная Россия” Единой государственной сети управления и передачи данных (ЕГСУПД), а та, в свою очередь, - к Единой системе передачи данных (ЕСПД) и общегосударственной автоматизированной системе управления (ОГАСУ) советских времен.
Первым в мире “стандартом” интероперабельности стал документ, подготовленный в Великобритании и получивший название “Модель интероперабельности электронного правительства”. Он был взят на вооружение практически всеми странами бывшего Британского содружества наций (как они это всегда делают со всеми правительственными документами такого рода) и после переработки превратился в аналогичные национальные документы. Некоторые другие страны, включая Россию, тоже создали свои модели интероперабельности, как показано в табл. 3.
Таблица 3. Стандарты интероперабельности передовых стран мира
| Страна, Web-сайт | Оригинальное название документа | Дата публикации | Комментарий |
Великобритания, www.govtalk.gov.uk/ schemasstandards/egif_ document.asp? docnum=857 | e-GIF. Part 1. Framework. Version 6. Draft for Public Consultation | Февраль 2004 г. | Модель интероперабельности электронного правительства Великобритании разработана при непосредственном участии офиса э-коммерции (E-commerce Office) и офиса э-посланника (E-envoy Office) и содержит положения технической политики, которую должны проводить ведомства. Модель включает профиль стандартов, являющихся основой для построения в стране электронного правительства. В спецификации e-GIF используются промышленные открытые стандарты, обеспечивающие обмен информацией между информационными системами госучреждений, а также между системами госучреждений и системами граждан и бизнеса |
Великобритания, www.govtalk.gov.uk/ schemasstandards/egif_ document.asp? docnum=858 | e-GIF Part 2. Technical Standards Catalogue. Version 6. Draft for Public Consultation | Февраль 2004 г. | Каталог технических стандартов содержит минимальный набор спецификаций стандартов, соответствующих технической политике, которая изложена в части 1 данного документа |
Великобритания, www.egifcompliance.org | e-GIF Compliance Assessment Service | Февраль 2003 г. | Создана система сертификации продуктов, удовлетворяющих спецификации e-GIF |
Австралия, www.agimo.gov.au/ publications/2003/ 08/framework | Interoperability Technical Framework for the Australian Government | Май 2003 г. | Сделано по образу английской модели |
Германия, www.kbst.bund.de/saga | SAGA ( Standards und Architekturen fuer eGovernment-Anwendungen), Version 1.1 | Февраль 2003 г. | Созданием э-правительства и разработкой стандартов интероперабельности для него занимается министерство внутренних дел Германии |
Гонконг, www.ogcio.gov.hk/ eng/infra/eif.htm | The HKSARG Interoperability Framework []. Version 3.0 | Ноябрь 2004 г. | Стандарты интероперабельности э-правительства Гонконга, специального административного района КНР (HKSAR), разработаны его департаментом ИТ-услуг |
Канада, www.cio-dpi.gc.ca/its-nit/ index_e.asp | Treasury Board information or technology standard | Январь 2004 г. | Модель интероперабельности утверждена комитетом стандартов по информации и технологиям Казначейства Канады для обязательного использования всеми федеральными ведомствами страны |
Новая Зеландия, www.e-gif.govt.nz | e-Government Interoperability Framework (e-GIF) | Ноябрь 2003 г. | Сделано по образу английской модели |
Россия, www.iaeg.ru/54317 | Проект “Концепция системы стандартов "Интеграционная платформа информационных систем органов государственной власти" | Внесен в октябре 2005 г. ООО “Ай-Ферст” | Сделано по образу английской модели |
США, www.whitehouse.gov/ omb/egov/ e-5-documents.html | Federal Enterprise Architecture Technical Reference Model (TRM) | Январь 2004 г. | Техническая эталонная модель федеральной архитектуры предприятия США предназначена для идентификации стандартов, спецификаций и технологий, поддерживающих поставку сервисных компонентов и средств |
Франция, www.adae.gouv.fr/ article.php3?id_article=219 | Le cadre commun d’interoperabilite des systemes d’information publics. Dossier d’introduction. Version 2.1 | Сентябрь 2003 г. | Французское агентство по электронной администрации (ADAE) при президенте Франции в сентябре 2003 г. выпустило версию 2.1 модели интероперабельности правительства |
Концепция интеграционной платформы
Исходной точкой для формирования концепции интеграционной платформы является формулировка набора ключевых положений (основного набора непротиворечивых постулатов и аксиом), обеспечивающих взаимодействие с требуемыми свойствами []. В качестве таких положений принято использование ряда следующих инструментов: расширяемого языка разметки XML [] в качестве основного инструмента интеграции и обеспечения совместимости; “бесшовной” интеграции ведомственных (ИС); моделей и схем метаданных на базе международной модели дублинского ядра (Dublin Core) [], UDDI-регистра [] и Workflow Management Coalition (WFMC) []. Сюда же относится построение профиля и набора референтных моделей деятельности (деловых процессов) структур органов государственной власти; механизмов управления деловыми (административными) процессами; анализ, а при необходимости и реинжиниринг существующих деловых процессов на всех уровнях государственной власти как непременного условия создания адекватной и эффективной интеграционной платформы [-].
Нужны целенаправленные и эффективные усилия соответствующих государственных структур (включая разумное использование “административного ресурса”), с тем чтобы обеспечить соблюдение требований стандартов интеграционной платформы в структурах органов власти.
При разработке интеграционной платформы унификация и стандартизация затрагивают архитектуру и профиль платформы; набор референтных моделей деятельности структур органов государственной власти (например, бюджетный и инвестиционный процессы, социальное обеспечение, строительство, благоустройство, образование, медицину и т. д.); протоколы; форматы данных и языки их описания; языки описания интерфейсов взаимодействия, включая протоколы взаимодействия и форматы передаваемых данных; механизмы публикации, поиска и обнаружения объектов взаимодействия, информационных ресурсов и сервисов, предоставляемых для электронного взаимодействия; механизмы управления деловыми процессами; языки описания деловых процессов.
Сложность разработки платформы обусловлена многообразием видов и типов информационных ресурсов, моделей деятельности федеральных, региональных и муниципальных структур власти, применяемых способов организации хранения и представления информации, подходов к выбору программных средств и используемых технологий доступа и т. п.
Формирование эффективных механизмов интеграции возможно только на основе единой интеграционной политики, при создании которой необходимо учитывать нормативно-правовые, организационные, функциональные, информационно-лингвистические, программно-технические и другие аспекты. Интеграционная платформа реализуется на базе двух парадигм - сквозного управления деловыми процессами и технологии Web-сервисов (сервисов). Данный выбор не случаен: в последнее время наблюдается интенсивное слияние этих технологий []. Интеграционная платформа реализуется таким образом, чтобы все подсистемы, функциональные комплексы и модули строились на единой технологической и методологической базе.
Для реализации основных свойств архитектура интеграционной платформы предоставляет всем участникам электронного взаимодействия понятные и адекватные механизмы, поддерживающие такие возможности, как описание деловых процессов; генерация работ; управление выполнением деловых процессов; мониторинг событий; публикация нормативно-правового и нормативно-технического обеспечения среды (документы, регламенты, стандарты и т. д.); публикация описаний поставщиков сервисов, информационных ресурсов и реализации сервисов; поиск и обнаружение документов, регламентов, стандартов и пр.; поиск и обнаружение описаний поставщиков, информационных ресурсов и реализации сервисов; передача сообщений между объектами электронного взаимодействия; единая точка входа для всех взаимодействующих структур ко всей совокупности информационных ресурсов на основе сервисов; разграничение доступа к вычислительным и информационным ресурсам и т. д.
Архитектурное решение, реализующее все указанные выше требования к платформе, показано в табл. 4. Оно предоставляет пользователям ясный и понятный механизм действий при выполнении работ, основанный на формализации описания делового процесса, а также единую точку входа к распределенным по разным структурам информационным ресурсам, включая хранилища аналитической информации, на основе сервисов в соответствии с правилами единой политики безопасности.
Таблица 4. Архитектура интеграционной платформы (на примере австралийского стандарта)
Интеграционная платформа надстраивается над существующей внутренней информационно-коммуникационной инфраструктурой. Система управления деловыми процессами является основным системообразующим элементом платформы. С ней тесно связан второй системообразующий элемент - портал. Эти два взаимоувязанных решения образуют ядро платформы, вокруг которого располагаются другие инфраструктурные элементы.
Связь между внутренней и внешней информационно-коммуникационной инфраструктурой реализуется посредством шлюза. За шлюзом располагаются федеральный, региональный или муниципальный портал, а также Web-сайты различных ведомств, обеспечивающие публичность деятельности органов государственной власти, взаимодействие с гражданами и бизнесом. Для организации межведомственного взаимодействия предусмотрен специальный шлюз. Вопросы обеспечения информационной безопасности при электронном взаимодействии возлагаются на подсистему защиты информации, обеспечивающую конфиденциальность, целостность, аутентификацию данных и криптографический контроль доступа. При этом уровень безопасности должен гарантировать практическую устойчивость защиты против любых попыток компрометации с использованием современных и доступных в ближайшие десятилетия вычислительных средств.
Учитывая большую сложность задач, решаемых при реализации электронного взаимодействия с применением интеграционной платформы, регламентацию ее создания и развития целесообразно осуществлять на основе системы управления качеством, соответствующей требованиям стандарта ISO 9001-2000. Этот стандарт предполагает системный подход к постановке менеджмента процессов электронного взаимодействия у всех его участников, обеспечивая тем самым постоянное повышение качества предоставляемых услуг.
Заключение
По сути, модель интероперабельности - это профиль стандартов, подразумевающий не один, а несколько (много) стандартов, упорядоченных и различных по назначению. Предполагается, что системы, которые сертифицированы на то, что в них действительно реализован стандарт интероперабельности, соединяются и взаимодействуют без специальных на это затрат.
В табл. 5 и 6 сведены воедино параметры зарубежных продуктов интеграционных технологий компаний Microsoft, IBM, Oracle и InterSystems с отечественными продуктами “Среда электронного взаимодействия” (СЭВ, сосредоточенная платформа) и “Распределенная среда электронного взаимодействия” (РСЭВ, распределенная платформа). Последние разработаны компанией “Ай-Ферст” в рамках ФЦП “Электронная Россия” по заданию Минэкономразвития РФ (www. economy.gov.ru/wps/portal/e-russia). Мы включили данные продукты в обзор, поскольку это первый случай, когда государство на деле поддержало создание отечественного универсального средства интеграции административных процессов, реализуемых в различных информационных системах-островах федерального, регионального и муниципального уровней.
| Уровень | Продукты | Примечания | |||||
| сервисов (номера соот- ветствуют иерархии сервисов в табл. 4) | IBM WebSphere | InterSystems Ensemble | Microsoft BizTalk | Oracle 10g | СЭВ (2004) | Р-СЭВ (2005) | |
1. Представ- ление данных | XML, индустриальные (SWIFT, EDI и т.д.), частные внутрикор- поративные разработки (требуется разработка) | XML, FlatFiles, SQL, индустриальные (SWIFT, EDI, HL7 и т.д.), частные разработки и т.д. (с использованием адаптеров). Внутренний формат сообщений - XML и/или объектный | XML, Flat Files, EDI, IDOC и т.д. с использованием адаптеров | Внешние: Text/XML; ABAP/4, EDI и другие через соответст- вующие адаптеры. Внутренний формат сообщений - XML | XML - основной формат; допол- нительно можно использовать WSIF- адаптеры, в том числе разра- ботанные для Oracle BPEL | XML - основной формат; дополнительно можно использовать WSIF-адаптеры | Если не требуется интегрировать устаревшие или неподдерживаемые системы, то поддержка дополнительных протоколов не является серьезным преимуществом, т. к. при необходимости можно реализовать дополнительный протокол в рамках архитектуры WSIF (WSDL) |
2.1. Средства поддержки бизнес- процессов | BPEL, WBI Modeler + Workflow | Графическая и/или программная среда для описания бизнес-процессов. Ensemble является средой выполнения бизнес-процессов . Средства для мониторинга бизнес-активности | Логика бизнес- процесса исполняется встроенной подсистемой BizTalk Server под названием Orchestration. Описание логики делается либо с помощью средств Visio, либо напрямую в Visual Studio.NET | Графическая среда Oracle Workflow Builder для координации потоков работ. Графическая среда Oracle BPEL Process Manager Designer для координации Web-сервисов | BPEL 1.1 (имеется графический конструктор), графические метрики процесса для отображения у пользователя | BPEL 1.1 (имеется графический конструктор), графические метрики процесса для отображения у пользователя в нотации BPMN | |
2.2. Средства формализации бизнес- процессов | BPEL, WBI Modeler | Описание на языке BPL на основе BPEL. Поддерживается графическое, XML- и объектное представление. Поддержка бизнес-правил и бизнес-метрик | Cтруктура бизнес- процессов описывается с использованием встроенного набора компонентов бизнес-логики. Поддержка BPEL | Реализована спецификация BPEL 1.1 в составе Oracle BPEL Process Manager. Графическое представление (ориенти- рованный граф) потоков работ в Oracle Workflow | BPEL 1.1, метрики | BPEL 1.1, метрики | BPEL в настоящее время является наиболее перспективным форматом описания бизнес-процессов (поддержана основными игроками рынка), поэтому поддерживать устаревшие стандарты нет смысла |
3.1. Специ- фикация, обнаружение, вызов Web-сервисов | WSDL, UDDI, RosettaNet registry | WSDL, UDDI. Возможность генерации кода Ensemble для взаимодействия с Web-сервисами интегрируемых систем | WSDL, UDDI, RosettaNet registry | WSDL, UDDI | WSDL, UDDI | WSDL, UDDI | UDDI является наиболее общепринятым стандартом ведения бизнес-реестров, поэтому поддерживать устаревшие стандарты нет смысла, если есть запас по производительности и не требуется интегрировать унаследованные системы |
3.2. Поддержка Web-сервисов | SOAP через HTTP и JMS | Полная поддержка стандартов WSDL и SOAP. Наличие мастера для быстрой публикации сервисов. Возможность предоставить доступ через Web-сервисы к интегрированным с помощью Ensemble приложениям. | Полная поддержка стандартов WSDL, UDDI и SOAP, включая стандарты безопасности. Также имеется возможность публиковать описания бизнес- процессов в качестве Web Service | Поддержка через адаптер | Поддержка UDDI, WSDL, SOAP | Поддержка UDDI, WSDL, SOAP, WS-Security | |
4. Защита информации | SSL, Tivoli Access Manager (готовое решение), корпоративные стандарты (дополнительная разработка) | SSL, возможность выбора метода авторизации, возможность подключения средств шифрации | Полностью интегрируется с системой авторизации Windows 2000, 2003 Server, использующей Active Directory, LDAP, поддержку SSL, и т.д. Реализована поддержка технологии Single Sign-On | SSL, безопасность транспортного уровня обмена сообщений обеспечивается механизмами Oracle Database | SSL, собственная система безопасности, поддержка JAAS | SSL, WS-Security, XML DigitalSignature, XML Encription, X.509 - поддержка удостоверяющих центров, поддержка JAAS | |
5. Преобра- зование данных | XSD, EDI, eb-XML | Data Transformation Language Ensemble позволяет использовать для преобразования графические средства и специальный код. Возможно использование XSD и XSLT | XSD, EDI, IDOC, поддер- живаются структурные преобразования данных | XSD, ABAP/4, EDI | XSD-схемы, XSLT- преоб- разования (репозитарий типов) | XSD-схемы, XSLT- преобразования, упрощенный формат репозитария типов (визуальный конфигуратор) | XSD совместно с WSDL позволяет описать практически любой формат данных и протокол взаимодействия, если есть запас по производительности и не требуется интегрировать унаследованные системы |
6.1. Технологии и механизмы взаимо- действия с другими инфор- мационными системами | CORBA, SQL-JDBC-ODBC, WBI-адаптеры | Библиотека адаптеров Ensemble (к файлам, СУБД, системам гарантированной доставки сообщений, Web-сервисам, протоколам и т. д.; всего более 250 адаптеров). Наличие Adapter SDK для разработки специали- зированных адаптеров | Файлы данных, адаптеры, веб-сервисы Файлы данных, адаптеры, веб-сервисы | Адаптеры, сервисы, WSIF- провайдеры | WSIF- провайдеры, Web-сервисы, адаптеры | WSIF-провайдеры, Web-сервисы, адаптеры | Благодаря использованию архитектуры WSIF в Oracle BPEL PM и Ensemble возможно использование как готовых адаптеров для этой архитектуры, так и написание частных |
6.2. Транспортные протоколы | SOAP, HTTP(s), JMS-MQM | Адаптеры Ensemble могут использовать в качестве транспорта TCP/IP, HTTP(S), FTP, SMTP, SOAP, JMS, и т. д., есть возможность использовать внешний транспорт (CICS, Tuxedo, SonicMQ, MS MQ, MQSeries и т. д.) | HTTP, FTP, SMTP, MSMQT, File, IBM MQSeries, SQL Server. Есть возможность реализовать любой собственный транспорт, используя Adapters Framework | FTP, SMTP, HTTP(S), JCA, JMS. Есть возможность реализовать собственный транспорт | FTP, SMTP, HTTP(S), JCA, JMS. Есть возможность реализовать собственный транспорт | FTP, SMTP, HTTP(S), File. Есть возможность реализовать собственный транспорт в рамках транспортной подсистемы | Использование (полу-) прозрачного транспортного уровня с внутренней системой адресации и маршрутизации в Р-СЭВ позволит легко решать проблемы обмена данными между ведомствами, в т. ч. находящихся в закрытых сетях |
6.3. Гарантия доставки и очередности сообщений | Обеспечение гарантированной доставки с использованием IBM MQ Series | Обеспечивается гарантированная доставка как за счет внутреннего транспорта, так и за счет внешних транспортов (например, MS MQT или MQ Series) | Обеспечение как гарантируемой доставки сообщений, так и их очередности с использованием в качестве транспорта MSMQT либо IBM MQ Series | Обеспечение гарантиро- ванной доставки с использо- ванием AQ (Advanced Queueing) | Может быть реализована с исполь- зованием JMS- совместимых систем (в составе Oracle Application Server имеется собственная реализация) | Может быть реализована с использованием транспортной подсистемы Р-СЭВ или JMS- совместимых систем | |
7. Сети | Любые (Интернет) | Любые (Интернет) | Любые (Интернет) | Любые (Интернет) | Любые (Интернет) | Любые (Интернет) за счет использования транспортной инфраструктуры в рамках Р-СЭВ могут поддерживаться, в т.ч. offline-передача данных |
Таблица 5. Сравнение технических характеристик интегрирующих продуктов основных игроков на ИТ-рынке РФ
| Потребительская | Продукты | |||||
| характеристика продукта | IBM WebSphere | InterSystems Ensemble | Microsoft BizTalk | Oracle 10g | СЭВ (2004) | Р-СЭВ (2005) |
Масштабирование | Вертикальная и горизонтальная масштабируемость, аппаратные и программные кластеры | Вертикальная и горизонтальная масшта- бируемость, кросс- платфор- менность, аппаратные и программные кластеры | Масштабируется как за счет аппаратного наращивания, так и за счет использования нескольких серверов, объединенных в кластер | Все компоненты допускают масштабирование: адаптеры, сервер приложений/ интеграционный брокер и база данных репозитория | 1. Горизонтальное масштабирование за счет разнесения функциональных компонентов. 2. Кластеризация исполнительного механизма BPEL | 1. Горизонтальное масштабирование за счет разнесения функциональных компонентов. 2. Кластеризация исполнительного механизма BPEL |
Возможность разработки без программирования | Разработка с помощью визуальных средств | Наличие визуальных средств разработки, мастеров, возможность подключения внешних инструмен- тальных средств | Разработка осуществляется с использованием визуальных средств, полностью интегрированных в Visual Studio .Net. Также есть инструменты, позволяющие аналитикам реализовывать бизнес-процессы с использованием Microsoft Visio | Разработка представлений данных в приложениях, преобразователей с помощью iStudio; проектирование потоков работ - Oracle Workflow | Визуальный конструктор BPEL и метрик процессов, поддержка преобразований данных с помощью репозитория типов данных | Визуальный конструктор BPEL и метрик процессов, поддержка преобразований данных с помощью репозитория типов данных |
Средства разработки | Поддерживаются единые средства разработки на базе Eclipse (WebSphere Studio-Rational) | Встроенная среда для разработки специа- лизированных адаптеров, бизнес- процессов, систем мониторинга бизнес- активности. Возможность разрабатывать композитные приложения с использованием Web-сервисов, Web-технологии Cache Server Pages, а также любых внешних инструмен- тальных средств (.Net, Java и т. д.), объектных и реляционных интерфейсов | Вся разработка в Microsoft Visual Studio .Net | Моделирование интеграционного сценария осуществляется в Interconnect iStudio + WorkFlow Builder или Oracle BPEL Process Manager Designer. Написание адаптеров осуществляется в Jdeveloper | Описание процедур электронного взаимодействия (ПЭВ) осуществляется в редакторе BPEL-сценариев и редакторе метрик. Дополнительные компоненты могут быть реализованы в любой среде разработки для языка Java | Описание ПЭВ осуществляется в редакторе BPEL-сценариев и редакторе метрик. Дополнительные компоненты могут быть реализованы в любой среде разработки для языка Java |
Простота доработки и расширения | Каждый компонент имеет собственные средства расширения (user exits, custom nodes, custom adapters, parsers) | Адаптеры: Adapter SDK входит в комплект поставки. Вся внутренняя логика описана с помощью классов с использованием объектной технологии и может быть легко расширена | Большие возможности по настройке без дополнительного программирования. Доработка и разработка дополнительных адаптеров и компонентов на базе .Net (VB, С# и т. д.). Все интерфейсы документированы | В случае необходимости могут быть написаны дополнительные адаптеры, трансформирующие функции и фильтры импорта метаданных из внешних источников. Язык программирования Java, интерфейсы открыты и документированы | Язык программирования Java, интерфейсы открыты и документированы. При необходимости могут быть реализованы адаптеры для сторонних систем и протоколов на уровне WSIF или Web-сервисов | Язык программирования Java, интерфейсы открыты и документированы. При необходимости могут быть реализованы адаптеры для сторонних систем и протоколов на уровне WSIF или Web-сервисов |
Перечень продуктов для реализации интеграционного решения | IBM WebSphere BI Server; WBI Adapters | Единый продукт InterSystems Ensemble. Других продуктов не требуется | Microsoft BizTalk Server; Microsoft SQL Server; Microsoft Visual Studio .Net | Могут использоваться все или некоторые из следующих: InterConnect, WorkFlow, ProcessConnect, BPEL Process Manager, Portal. Необходимой составляющей является СУБД Oracle | Oracle Application Server 10g, Oracle Database, Apache Tomcat 5.0.28 | Apache Tomcat 5.0.28, Microsoft SQL Server/Oracle Database 9/PostgreSQL 8 |
Схема лицензирования | По процессорам серверов | Две схемы лицензирования: по процессорам серверов или по пользователям в случае поставки Ensemble как встроенной платформы прикладного интеграционного решения | Microsoft BizTalk Server 2004 - лицензия на процессор; Microsoft SQL Server 2000 - лицензия на процессор, а также лицензии на сервер и клиентское рабочее место; Microsoft Visual Studio .Net 2003, лицензия на клиентское рабочее место | Все перечисленные продукты поставляются в составе Oracle Application Server EE. Oracle BPEL Process Manager лицензируется как дополнительная опция или отдельный продукт. Всегда необходимо лицензировать БД Oracle под репозиторий | За один сервер без учета числа процессоров. Продукт требует наличия Oracle Database 9i и Oracle Application Server 10g | За один сервер без учета числа процессоров. В зависимости от типа узла Р-СЭВ продукт требует наличия Oracle Database или Microsoft SQL Server 2000 |
Стоимость лицензии | IBM WebSphere BI Server - $ 117 700 за лицензию на один процессор | Зависит от схемы лицензирования. При попроцессорном лицензировании - от $60 000 за процессор, при лицензировании по пользователям - от $1200 за пользователя | Microsoft BizTalk Server 2004 Enterprise Edition - $25 000 за процессор; Microsoft BizTalk Server 2004 Standard Edition - $7000 за процессор | Oracle Application Server EE - $20 000 за процессор | $60 000 за сервер; Oracle Application Server EE - $20 000 за процессор; Oracle BPEL PM - $10 000 за процессор | Муниципальный и региональный узлы - $15 000 за один сервер; бесплатно для госорганизаций Федеральный узел - $60 000 за один сервер; Oracle Application Server EE - $20 000 за процессор; Oracle BPEL PM - $10 000 за процессор |
Таблица 6. Сравнение потребительских характеристик интегрирующих продуктов основных игроков на ИТ-рынке России
Литература
1. Демидов А., Свистунов А. Интеграционная среда электронного взаимодействия / www.iac.spb.ru.
2. XML (Extensible Markup Language) / www.w3.org/TR/2004/REC-xml-20040204.
3. Метаданные дублинского ядра для простого открытия ресурса (The Dublin Core Metadata for Simple Resource Discovery) / www.dublincore.org.
4. UDDI - www.uddi.org.
5. Business Process and Workflow Management Coalition / www.wfmc.org.
6. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии. - М.: Финансы и статистика, 1997. - 336 с.
7. Junichi Tatemura, Wang-Pin Hsiung, Wen-Syan Li. Acceleration of Web Service Workflow Execution through Edge Computing / www.www2003.org/cdrom/papers/ alternate/P172/p172-tatemura/p172-tatemura. html.
8. Workflow Process Definition Interface - XML Process Definition Language (XPDL) / www.wfmc.org/standards/docs/ TC-1025_10_xpdl_102502.pdf.
9. Business Process Modeling Language (BPML) / www.bpmi.org.
10. Web Services Flow Language (WSFL 1.0) / www-306.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf.
11. Web Services for Business Process Design (XLANG) / www.gotdotnet.com/team/ xml_wsspecs/xlang-c/default.htm.
12. Workflow Management Coalition. Terminology & Glossary. WFMC-TC-1011 / www.wfmc.org/standards/docs/if19807r10.pdf.
13. Workflow Management Coalition. The Workflow Reference Model. WfMC-TC00-1003, 1995 / www.wfmc.org.
14. Данилин А.В. Технологии интеграции государственных информационных систем и организации межведомственного взаимодействия / www.microsoft.com/ Rus/Government/analytics/integration/ default.mspx.
15. ГОСТ Р ИСО/МЭК 15408-2002. Информационная технология. - Методы и средства обеспечения безопасности. - Критерии оценки безопасности информационных технологий. Ч. 1, 2, 3.
