Держава у XXI сторіччі > Статті та дослідження > Технології інтеграції державних інформаційних систем і організації міжвідомчої взаємодії

Огляд технологій інтеграції інформаційних систем

Автор:

А. В. Данілін, менеджер по роботі з державними організаціями представництва Microsoft у Росії і СНД

Опубліковано: 2003 рік

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

Основні компоненти архітектури міжвідомчої взаємодії

Корпорація Microsoft була головним виконавцем ряду проектів, де забезпечення міжвідомчого інформаційного обміну відігравало першорядне значення, включаючи проект зі створення урядового шлюзу Великобританії. Ця робота дозволила накопичити унікальний досвід, який сконцентрований в архітектурі міжвідомчої взаємодії, що включає наступні основні компоненти:

XML як універсальний формат інформації/документів і обміну ними.
Середовище гарантованої доставки і маршрутизації інформації і XML-документів на базі стандартних Інтернет-протоколів. Сюди входить популярний продукт Microsoft BizTalk Server, що надає стандартні конектори для інтеграції додатків, а також засоби, що дозволяють визначати, розгортати і підтримувати інтегровані бізнес-процеси.
Реалізація державних інформаційних систем у вигляді веб-служб, що являють собою програмні компоненти додатків, доступні на основі відкритих стандартних Інтернет-протоколів і виконуючі певні бізнес-функції.

Для пояснення терміну веб-служба наведемо приклад того, яким чином дві роз'єднані відомчі системи можуть бути представлені у вигляді веб-служб і які послуги вони можуть надавати один одному в процесі взаємодії. Відомча система документообігу по своїй суті складається з набору певних послуг. Розглянемо процес обміну інформацією між системами документообігу двох різних державних установ. Система першої установи може переслати певний документ у систему другої установи і запросити деяку відповідь. У якості однієї з послуг система документообігу другої установ може, наприклад, повернути свій внутрішній реєстраційний номер документу, прізвище відповідального виконавця, контрольну дату відповіді тощо. Ще однією послугою може бути публікація і пересилання відповідного документа.

Класифікація технологій інтеграції

На рівні окремої організації проблема інтеграції виникає одразу, як тільки в ній впроваджується кілька корпоративних додатків. Як видно з попереднього розділу, на рівні країни, регіону чи міста надання послуг державою громадянам і бізнесу і реалізація інших ділових процесів у державі вимагає також інтеграції систем і даних.

Можна дати наступну класифікацію технологій інтеграції:

Системи інтеграції корпоративних додатків (Enterprise Applications Integration, EAI) — технології, орієнтовані на розв'язання проблем інтеграції різних систем, додатків і даних всередині окремої організації. Іноді для цих технологій використовується абревіатура A2A (Application-to-Application — додаток-додаток).
Системи інтеграції між організаціями (міжвідомчої інтеграції) Business-to-Business(Business-to-Business Integration, B2Bi) — технології, орієнтовані на забезпечення безпечного, надійного інформаційного обміну між різними організаціями і їхніми інформаційними системами. Ці технології забезпечують пересилання інформації за межі мережних екранів (firewall) і дають можливість автоматизувати бізнес-процеси в рамках «розширених організацій», що включають постачальників, партнерів, споживачів продуктів і послуг тощо.
Технології управління бізнес-процесами (Business Process Management, BPM), що є результатом природної еволюції класичних систем документообігу і діловодства (workflow systems) і систем класу EAI і B2Bi. Традиційні системи управління документами орієнтувалися в основному на пересилання інформації між людьми, що виконували певні дії. На відміну від технологій B2Bi, які орієнтовані на інтеграцію даних у міжвідомчому середовищі, технології BPM інтегрують дані, додатки і людей через єдині бізнес-процеси. Це відображує сучасну точку зору, що основою інтеграції повинні бути бізнес-процеси. Причина тут полягає в тому, що бізнес-процеси організації «перетинають» межі різних додатків, департаментів і організацій.

Наступна таблиця показує різницю між згаданими класами систем.

Технологія	Хто приймає рішення про використання	Розв'язувана проблема
Workflow	Керівник департаменту, відділу	Управління документами і пересилання документів
EAI і B2Bi	Керівник департаменту інформаційних технологій	Інтеграція даних
BPM	Вище керівництво організації (бізнес-керівництво)	Поліпшення виконання бізнесів-процесів і підвищення ефективності роботи за рахунок більшої гнучкості процесів

Традиційні технології інтеграції корпоративних додатків EAI і міжвідомчої інтеграції B2Bi базуються на використанні так званого брокера (вузла пересилання, шлюзу) повідомлень. Основу розглянутого раніше Урядового шлюзу Великобританії також складає брокер повідомлень.

Технологічним фундаментом брокера повідомлень є, як правило, програмне забезпечення проміжного шару пересилання повідомлень (Messaging-Oriented Middleware, MOM), що забезпечує транспорт доставки інформації і даних між прикладними системами. Прикладом такого програмного забезпечення є «сервер черг повідомлень» MSMQ (Microsoft Message Queuing). Продукти цього класу забезпечують транспорт гарантованої доставки повідомлень між додатками в територіально розподіленому середовищі. Підхід до інтеграції додатків на основі продуктів класу MOM став стандартним в сфері інтеграції корпоративних інформаційних систем наприкінці 90-х років.

Базова ідея цієї технології полягає в наступному. Припустимо, що існує кілька додатків, зв'язаних певним комунікаційним середовищем, але, можливо, не дуже надійним. Один додаток (наприклад, система документообігу A) повинен переслати інформацію/документ іншому додатку (системі документообігу B). Система A передає документ серверу пересилання повідомлень і «забуває» про нього. Сервер пересилання повідомлень забезпечить гарантовану й однократну доставку інформації в систему B.

Якщо при цьому інтегровані додатки знаходяться всередині організації в рамках однієї корпоративної мережі, то забезпечується пересилання інформації в режимі, «близькому до реального часу».

Якщо інтегруються додатки, які знаходяться в різних організаціях, то принцип «черги повідомлень» і гарантованої доставки, що реалізується MOM-продуктами, забезпечує асинхронна взаємодія і так зване «слабке зв'язування» . Додаток організації A не вправі очікувати на миттєву доступність додатку організації B, але програмне забезпечення гарантованої доставки повідомлень бере на себе відповідальність за доставку інформації між ними.

Роль урядового шлюзу в інтеграції інформаційних систем

Необхідність наявності такого інтеграційного елементу, як урядовий шлюз, не є очевидною в умовах, коли надання послуги не вимагає інформаційного обміну між відомствами або коли число залучених до взаємодії відомств невелике. Зрештою, при невеликій кількості відомств можна організувати взаємодію за принципом «кожний з кожним» і написати відповідні незалежні інтерфейси обміну.

Але на етапі реалізації надання державою електронних послуг, що вимагають виконання транзакцій і пов'язаного з ними інформаційного обміну між декількома відомствами, виникає необхідність створення служби інтеграції інформаційних систем різних відомств між собою. У противному разі задача інтеграції за принципом «кожний з кожним і усі з усіма» призведе до квадратичного росту складності, а, виходить, і вартості такої інтеграції. Наявність одного вузла, однієї точки інтеграції на основі брокера повідомлень дозволяє впоратися з ростом складності задачі інтеграції в міру підключення нових інформаційних систем. По суті справи це є однією з задач, виконуваних урядовим шлюзом Великобританії. При цьому шлюз виконує не тільки маршрутизацію повідомлень (які є XML-документами) між інформаційними системами різних державних структур, але і виконує також задачу трансформації цих повідомлень на основі відповідних XML-схем з метою забезпечення сумісності інформаційних систем.

Компоненти брокера повідомлень

Сьогодні брокери повідомлень можуть поєднувати велику кількість взаємодіючих систем. Результатом цього є те, що компанія Gartner Group називає «Корпоративною нервовою системою», тобто інфраструктура брокера повідомлень, до якої легко можуть бути підключені по суті справи будь-які додатки, і яка забезпечує взаємодію між ними в режимі, близькому до реального часу.

Мал. 1. Брокер повідомлень

Брокер повідомлень інтегрує гетерогенні додатки і сховища даних і надає три типи служб:

Пересилання повідомлень і переміщення даних забезпечує фізичний транспорт доставки повідомлень між додатками. Це може бути зроблено на основі таких Інтернет-протоколів, як Hypertext Transfer Protocol (HTTP) і традиційних систем пересилання повідомлень, наприклад Microsoft Messaging Queuing і IBM MQ Series. Перші покоління цих технологій використовували власні закриті формати для своїх повідомлень. Останнім часом мовою опису повідомлень усе більше стає XML.
Інтелектуальна маршрутизація, що визначає для кожного повідомлення те, до якого додатку воно повинно потрапити. Маршрутизація часто включає механізми публікації і підписки, коли серверний додаток один раз «публікує» деяку бізнес-подію для брокера повідомлень, а певна кількість інших бізнесів-додатків, зацікавлених у даній події, «підписуються» на нього.
Трансформування забезпечує мапування (визначення відповідності) даних між потенційно різними семантиками одного додатка чи різних додатків. Так, якщо один додаток використовує у форматі своїх дані літери «Ч» і «Ж» для опису статі людини, а інший додаток використовує для такого кодування «1» і «0», то рівень трансформації брокера повідомлень може мапувати інформацію між додатками, не змінюючи логіку кожного з них. У більш складних ситуаціях, коли один додаток може очікувати 5 атрибутів у записі про клієнта, а інший додаток забезпечує ці ж атрибути в двох різних записах баз даних, рівень трансформації може забезпечити мапування між такими різними структурами даних.

Архітектура брокера повідомлень може включати дві додаткові високорівневі служби:

Управління бізнес-процесами (оркестрування бізнесів-процесів) доводить рівень інтелектуальної маршрутизації до можливостей автоматизації потоків робіт (workflow), які повністю обслуговують внутрішні і зовнішні процеси;
Моніторинг процесів і подій перетворює брокер повідомлень на центр інформаційних потоків всередині і поза межами підприємства, а також забезпечує функції аналізу бізнес-операцій у масштабі, близькому до реального часу.

Крім цього, брокери повідомлень, як правило, підтримують роботу зі специфічними адаптерами для різних типів додатків і даних:

адаптери до веб-служб;
адаптери до моніторів транзакцій;
адаптери до різних реляційних СУБД;
API-адаптери для популярних коробкових додатків.

Наявність зазначених додаткових високорівневих служб, а також засобів для моделювання процесів (графічних засобів опису і модифікації процесів), по суті справи, перетворює системи EAI і B2Bi на системи класу BPM (системи управління бізнес-процесами).

Сервер Microsoft BizTalk Server являє собою саме таку систему управління бізнес-процесами (BPM), що забезпечує широкий набір засобів для визначення складних бізнесів-процесів, у яких можуть брати участь зовнішні організації. BizTalk Server містить у собі:

Графічні засоби визначення складних, розподілених і довготривалих (години, дні, тижні) бізнесів-процесів. Ці засоби мають можливість поділу логіки бізнесів-процесів і фізичної реалізації.
Засоби візуального визначення структурованих бізнесів-документів.
Засоби мапування (визначення відповідності) між різними форматами бізнесів-документів, включаючи можливості встановлення правил трансформації.
Засоби управління (консоль) для визначення організацій, залучених до бізнес-процесів, і засоби визначення правил взаємодії та обробки повідомлень.
Засоби аналізу, відстеження і збереження документів для наступного аналізу.
Засоби моніторингу і управління роботою інтеграційного шлюзу.

Базові принципи інтеграції з використанням XML і веб-служб

Отже, основою міжвідомчої інтеграції може служити інтеграційне програмне забезпечення і системи управління бізнес-процесами (BPM), такі як, наприклад, Microsoft BizTalk Server. При цьому XML претендує на роль універсального формату даних при такій інтеграції. А самі відомчі системи, як знов розроблювані, так і успадковані, можуть бути реалізовані у вигляді так званих веб-служб або можуть зробити свої інтерфейси доступними у вигляді веб-служб.

Мал. 2. Гіпотетична система видачі посвідчення водія, що використовує XML

Щоб прояснити суть цих підходів до організації міжвідомчої взаємодії та інтеграції інформаційних систем, розглянемо прості базові поняття, пов'язані із стандартами XML і веб-службами. Перше і головне, що слід зазначити, — це те, що всі описані нижче стандарти є відкритими, а в їхній розробці беруть участь такі провідні ІТ-компанії, як Microsoft і IBM, а також органи стандартизації Інтернет-співтовариства в особі консорціуму World Wide Web Consortium (W3C) і організації UDDI.org. Це має особливу важливість, оскільки держава повинна орієнтуватися на відкриті стандарти інтеграції.

Друге. Дані технології не залежать від платформи і не вимагають від організацій, чиї додатки інтегруються, використання таких загальних платформних продуктів, як операційні системи і СУБД.

По своїй суті XML — це мета-мова для представлення даних. Термін «мета» використовується тому, що XML-документ не тільки містить у собі дані, але також несе інформацію, що описує ці дані. XML є такою ж універсальною і базовою технологією для представлення, трансформації і обміну даними, як транспортний протокол Transmission Control Protocol/Internet Protocol (TCP/IP) для Інтернету.

XML надає загальний формат для пересилання даних між додатками. При цьому самі дані можуть як і раніше зберігатися в прикладних системах і базах даних у своєму внутрішньому форматі, але в разі потреби їхнього пересилання в інший додаток вони будуть трансформуватися у формат XML, як у проміжний формат, що розуміється всіма системами. Уже сьогодні стандарт XML підтримується постачальниками основних платформних програмних продуктів.

Усе це не усуває необхідності використання програмного забезпечення проміжного шару пересилання повідомлень (MOM), про яке мова йшла вище, оскільки потік XML-даних і документів повинен бути відповідним чином маршрутизований і, можливо, трансформований для того, щоб бути зрозумілим цільовим додатком.

При цьому XML-дані мають текстовий формат і можуть аналізуватися мережними екранами і проходити за межі організацій.

Таким чином, XML пропонує єдине рішення як для інтеграції корпоративних додатків (EAI або A2A), так і для міжвідомчої B2Bi-інтеграції.

Одна з тенденцій полягає в тому, що найбільш передові продукти інтеграції класу систем управління бізнес-процесами (BPM), такі як Microsoft BizTalk Server, не тільки використовують XML як формат обміну даними, але також використовують синтаксис мови XML для опису бізнес-логіки і контролю маршрутів і потоків проходження повідомлень і документів. Зокрема, Microsoft, IBM і ряд інших постачальників розробили мову Business Process Execution Language for Web Services (BPEL4WS) як стандартну XML-мову опису бізнесів-процесів. Це забезпечує те, що нові додатки буде ще легше інтегрувати в загальні бізнес-процеси, а сама логіка бізнес-процесів може бути легко доступною для модифікації. Це також дає можливість створення репозитарія стандартних державних бізнесів-процесів, що лежить в основі електронних адміністративних регламентів.

Ще одна тенденція полягає в тому, що прикладні системи все в більшому ступені реалізуються у вигляді компонентів, так званих веб-служб, функціональні можливості яких доступні для користувачів і інших додатків по мережі Інтернет/інтранет.

У цьому плані системи управління бізнес-процесами (BPM) і технологія веб-служб прекрасно доповнюють один одного. Прикладні системи, що інтегруються, і їхні модулі можуть бути реалізовані в якості чітко визначених служб. Системи BPM забезпечують виконання потоків робіт як ланцюжків взаємозалежних служб, «склеюючи» разом служби в єдині бізнес-процеси.

Нижче наводиться інформація про ключові стандарти веб-служб: XML, SOAP, WSDL і UDDI. Але спочатку розглянемо коротко процес взаємодії додатків у децентралізованому, розподіленому середовищі. Додаток, якому потрібен доступ до іншого додатку як до веб-служби, використовує регістр (каталог) UDDI для виявлення потрібної йому веб-служби (інформація в регістрі UDDI попередньо повинна бути опублікована організацією, що бажає зробити свою веб-службу публічно доступної). У цьому ж регістрі додаток визначає необхідні для взаємодії інтерфейси. Інтерфейси публікуються з використанням стандарту WSDL. Після цього за допомогою інтерфейсу WSDL додаток викликає веб-службу і застосовує SOAP і XML як конверти і формати для передачі інформації, а протоколи HTTP і SMTP — як транспорт для її доставки.

Таким чином, технологія веб-служб забезпечує загальний формат даних (XML), спосіб доставки і транспортування даних по Інтернету і інтранет-мережі (SOAP), а також спосіб виявлення (UDDI) і опису (WSDL) служб.

Основні стандарти XML і веб-служб

Інтеграція інформаційних систем на основі веб-служб пов'язана з використанням чотирьох ключових стандартів:

Extensible Markup Language (XML) — розширювана мова розмітки інформації. Описує інформацію, що пересилається по Інтернету. Запит на одержання яких-небудь даних чи виконання певних дій іншим додатком вимагає наявності способів передачі параметрів і одержання назад певних результатів. При використанні веб-служб ця інформація описується за допомогою мови XML, що є міжнародним загальноприйнятим стандартом для опису довільних даних, якими у свою чергу можуть обмінюватися інформаційні системи. Нижче буде наведено простий приклад XML-документа, з якого навіть нетехнічному фахівцю стане зрозумілою основна ідея цієї мови.
Simple Object Access Protocol (SOAP) — простий протокол доступу до об'єкта. Цей стандарт описує протокол виклику веб-служби (віддалений процес доступу до послуг/інформації деякої прикладної системи). Тобто передані параметри описуються за допомогою мови WSDL, а сам процес виклику описується за допомогою SOAP. Іншими словами, цей протокол немов би описує конверт з інформацією для виклику веб-служби. І цей конверт може бути доставлений від одного додатка до іншого за допомогою таких транспортних протоколів як Hypertext Transfer Protocol (HTTP) чи протоколів електронної пошти на зразок Simple Mail Transfer Protocol (SMTP). У типовій ситуації взаємодії система однієї організації може викликати систему іншої організації, використовуючи протокол SOAP. Запит, що зазвичай містить ту чи іншу форму бізнес-документа, посилається ініціатором до запитуваної системи. Остання приймає запит, і вхідний документ, який міститься в запиті, обробляється. У результаті запитана система генерує відповідь, що повертається ініціатору взаємодії. Ініціатор також інформується про статус (успіх або інше) запиту. Протокол SOAP заснований на стандарті XML і складається з трьох частин: формат конверту, що описує вміст повідомлення і те, як воно повинне оброблятися; набір правил кодування для визначення типів даних конкретного додатка і угоди з виконання віддалених викликів процедур.
Web Services Description Language (WSDL) — мова опису веб-служб. Це мова, яка базується на стандарті XML, що визначає спосіб доступу до веб-служб. Вона описує функціональні можливості веб-служб і групує операції взаємодії у певні інтерфейси, що задають способи виконання операцій і ті параметри, які повинні бути на вході і виході.
Universal Description, Discovery, and Integration (UDDI) — універсальний метод опису, виявлення та інтеграції. Технологія UDDI надає засоби, за допомогою яких можна зробити так, щоб будь-які додатки чи послуги, описані в термінах веб-служб, можуть бути розпізнані іншими додатками та/або організаціями. Тобто це стандарт створення регістра, використовуючи який, можна описати організації і послуги, які вони надають, у вигляді, доступному для динамічного виявлення і взаємодії. Основні об'єкти інформаційної моделі UDDI — це організації (businessEntity), послуги (businessService) і поєднуючий шаблон (bindingTemplate), що відповідають, за аналогією із звичайними телефонними довідниками, так званим білим сторінкам (адресна і контактна інформація), жовтим сторінкам (послуги, що надаються) і зеленим сторінкам. У традиційних телефонних довідниках наявність зелених сторінок, що описують способи одержання послуги, не була необхідною, оскільки передбачається, що телефонний зв'язок є єдиним способом доступу. Специфікацією UDDI передбачається довільна множина методів звертання до кожної веб-послуги, для опису яких і служить поєднуючий шаблон.

Основи XML

На відміну від «закритих» стандартів інформаційного обміну, наприклад Electronic Document Interchange (EDI), XML був спроектований таким чином, щоб фахівець, що читає XML-документ, міг зрозуміти його зміст. Наступною основною ідеєю розробників було створення такої мови, яка б забезпечувала можливість опису структури інформації і документів, що дозволяє не тільки людям, але і системам інтерпретувати зміст документа і витягати необхідну інформацію.

При цьому використовується набір так званих тегів, що описують структуру інформації.

Наведений нижче приклад показує, як «Президент Іван Іванович Іванов» може бути «описаний» у вигляді XML-документа.

<?xml version="1.0"?>
<OFFICE RANK="1">Президент></OFFICE>
<NAME>
	<FIRST>Іван></FIRST>
	<MIDDLE>Іванович></MIDDLE>
	<LAST>Іванов></LAST>
</NAME>

XML-тегі використовуються для того, щоб показати, який тип даних являє собою кожне з цих чотирьох слів: «Президент», «Іван», «Іванович», «Іванов». Тег NAME застосовується для структурування трьох тегів більш нижчого рівня ієрархії FIRST (для опису імені), тег MIDDLE — для опису по-батькові і тег LAST — для опису прізвища. Усі XML-документи мають можливість структурувати дані аналогічним ієрархічним способом. Наведений тут приклад містить у собі також використання атрибута даних — ранг офісу «1», призначений офісу Президента.

Ключовими елементами XML є тегі, елементи, атрибути, схеми і простори імен.

Тег — це, як правило, слово, обмежене кутовими дужками, наприклад. Тегі використовуються парами для позначення початку і кінця елементу. Тег, що закінчує елемент — цей той же самий тег, що починає елемент, але тільки він починається із символу косої риски. Кожний елемент містить текст, що має відношення до даного тегу. Так, в елементі

<Account><nobr>729—1269-4785</nobr></Account>

текст між двома тегами може являти собою номер якогось банківського рахунка чи єдиний номер громадянина для виплати соціальної допомоги. Аналогично, в елементі

<Balance>3822.55</Balance>

текст між тегами може представляти кількість грошей, що знаходяться на рахунку, або позначати розмір соціальної допомоги. Остаточна інтерпретація того, що означає той чи інший тег — номер рахунка в банку або розмір соціальної допомоги — залежить від домовленостей розробників системи або від використання так званої схеми, що забезпечує правила інтерпретації XML-документів.

Маючи необхідний набір тегів можна створити XML-документ, що буде в зрозумілий спосіб описувати певну інформацію. Наприклад, можна створити простий документ, що містить інформацію про людину, номер для виплати йому соціальної допомоги і її розмір, використовуючи ті тегі, які щойно були описані вище.

Початковий тег елементу може також містити один і більше атрибутів. Кожен атрибут описує певний аспект відповідного елементу. Так, в елементі

<OFFICE RANK="1">Президент</OFFICE>

атрибут типу показує, що офісу Президента наданий вищий статус, у даному випадку — «1». Елементи є основою XML-документів. Але тут виникає питання: а як визначати зміст усіх цих елементів? Повинен існувати спосіб опису груп елементів (і, виходить, тегів), що будуть використовуватися для певних цілей. Наприклад, який набір тегів повинен використовуватися в країні для опису громадянина (його імені, дати народження, адреси проживання та ін.) у базі даних, що використовується для забезпечення виборів чи в інших системах.

Для цього призначена так звана схема. Кожна схема визначає один чи більше елементів, а також правила їх застосування. Схема, наприклад, може визначати елемент Envelope (Конверт), обмежений тегами і потім визначати те, що цей елемент може містити всередині себе одне чи кілька входжень елемента Body (Тіло документа), обмежене тегами і .

Якби один документ містив тегі, що визначаються тільки однією схемою, то життя було б дуже простим. У загальному випадку, однак, в одному документі містяться елементи, визначені двома і більш схемами. Схеми можуть створюватися незалежними людьми й організаціями, тому існує імовірність того, що один і той самий тег у кожній схемі використовується для позначення різних понять. Наприклад, тег в одній схемі може бути визначений як номер рахунка, в іншій схемі він може використовуватися як єдиний номер громадянина для виплати соціальної допомоги. Для того, щоб було можливо використовувати різні схеми в одному й тому самому документі, повинен існувати спосіб асоціювання елемента з тією схемою, у якій він визначений. Для забезпечення такого зв'язку використовується механізм простору імен (namespaces).

Простір імен дає спосіб забезпечення глобальної унікальності імен для наборів елементів. Кожний простір імен визначається за рахунок використання Єдиного ідентифікатора ресурсів (Uniform Resource Identifier, URI), що виглядає як знайоме багатьом URL-посилання на ресурси Інтернету (Uniform Resource Locater, URL). Простір імен, у якому визначений елемент, може бути специфікований з використанням атрибута.

Наприклад, в елементі

<Account xmlns="http://www.qwickbank.com/bank“>
<nobr>729-1269-4785</nobr>
</Account>

атрибут xmlns вказує, що елемент Account визначений у просторі імен, заданому URI. Успіх використання XML і веб-служб для інтеграції державних інформаційних систем залежить від здатності досягти загальних домовленостей на рівні країни, регіону, міста тощо із приводу стандартів на тегі для представлення даних у XML-документах. Наприклад, два взаємодіючих додатки повинні однаково трактувати певний тег Person з описом особистої інформації громадянина і всі підрядні атрибути цього тега. Тобто повинен існувати організаційний механізм обговорення і прийняття відповідних схем XML-документів, аналогічний механізму, описаному в розділі „Середовище міжвідомчої взаємодії e-GIF у Великобританії“ нижче в даному документі.

Нарешті, хоча це і не так важливо зі смислової точки зору, XML-документ може містити коментарі. Коментарі дозволяють включати інформацію, призначену не стільки для комп'ютера, що обробляє XML-документ, скільки для людини, яка його читає. Коментар у XML-документі виглядає так:

<! — Це XML-документ —>

Безсумнівно, XML містить набагато більше ідей, ніж ті, які щойно обговорювалися. Однак навіть цих знань достатньо, щоб мати базове розуміння того, як XML може використовуватися в якості універсальної мови інформаційного обміну і що таке веб-служби.

Тим, хто хоча б трохи знайомий з мовою розмітки HTML, що використовується для представлення інформації в Глобальній мережі, може бути корисною наступна таблиця, що порівнює мови HTML і XML.

HTML	XML
Тегі попередньо визначені і служать інструкціями для форматування і відображення	Тегі даних не визначені і можуть бути використані як помітки даних у будь-якій ієрархічній структурі
Дані в HTML-документі, загалом, не можуть бути інтерпретовані і оброблені без втручання людини	Дані в XML-документі можуть бути автоматично інтерпретовані і оброблені системою, що підтримує XML
Сильна сторона — відображення інформації за допомогою веб-оглядача	Сильна сторона — забезпечення можливості обміну інформацією
HTML спроектований так, що він може допускати синтаксичні помилки і сфокусований на відображенні інформації	XML спроектований з урахуванням перевірки синтаксичних помилок і забезпечення відповідності структурі даних (чи шаблонам), коли вони задані

Спільні моменти

Обидві є відкритими стандартами, затвердженими консорціумом W3C, що потенційно можуть працювати на різних комп'ютерних системах.
Обидві спираються на Інтернет-протоколи з погляду транспорту і підключення до широкого спектру систем.
Обидві засновані на Стандартній узагальненій мові розмітки (Standard Generalized Markup Language) і тому структуровані як текстові файли, що можуть бути прочитані і зрозумілі людьми.

Особливу цінність представляє можливість трансформування даних XML-документа для відображення на різних пристроях або для відповідності форматові даних конкретного додатка.

Можна мати один екземпляр XML-документа, але зовсім різним образом виводити його на різних пристроях, за допомогою яких користувач намагається одержати до нього доступ. Різні пристрої — ПК, персональні помічники типу iPAQ чи Palm, мобільні телефони — мають різні можливості для відображення інформації, тому той самий XML-документ може бути відображений по-різному, за рахунок використання таблиць стилів (Style Sheet), що описуються з використанням мови XSL (eXtensible Stylesheet Language), що сама по собі використовує формат XML. Це, по суті, текстовий файл формату XML, що надає інструкції з форматування і відображення інформації XML-документа. Таблиця стилів може містити варіації в залежності від типу пристрою, на якому відображається документ.

Мал. 3. XML може забезпечити відображення інформації на різних пристроях користувачів

При використанні XML для інтеграції даних між додатками механізм трансформації, відомий як XSLT (XSL Transformation, XSLT) може забезпечити те, що документ типу „Заявка на купівлю“ інформаційної системи організації A буде при пересиланні трансформований в документ типу „Замовлення на постачання“ формату інформаційної системи організації B.

Цей механізм незалежного виконання правил трансформування інформації при пересилання між додатками дуже важливий, оскільки рятує від необхідності внесення змін у додатки в процесі їх інтеграції.

Враховуючи наведену вище інформації про мову XML і інші пов'язані з нею стандарти стає зрозумілим більш точне практичне визначення того, що таке веб-служба, відповідно до визначення компанії Gartner Group: „Веб-служба — це програмні компоненти, які використовують одну або декілька технологій з наступного списку — SOAP, WSDL і UDDI — для виконання розподілених обчислень. Використання кожної з цих базових технологій — SOAP, WSDL або UDDI — становить суть веб-служби. Використання їх усіх разом не обов'язкове“.

Базові принципи застосування XML і веб-служб для організації міжвідомчої взаємодії

Нижче перераховані основні принципи застосування XML і веб-служб для організації міжвідомчої взаємодії:

веб-служби як основний механізм інтеграції. Системи окремих державних органів, включаючи системи документообігу, можуть бути описані у вигляді веб-служб;
XML як стандарт обміну даними;
можливість створення загальнодоступних регістрів відомчих систем на федеральному, регіональному і місцевому рівнях за допомогою універсального стандарту UDDI;
„слабке зв'язування“ інформаційних систем на основі інфраструктури пересилання повідомлень у вигляді XML-документів.

Мал. 4. Технічна модель веб-служб XML як технології інтеграції

Таким чином, ключовим принципом застосування XML для міжвідомчої інтеграції інформаційних систем, у тому числі систем документообігу, є використання веб-служб і регістрів на базі універсального стандарту UDDI. Причому UDDI може використовуватися для створення загальнодоступного регістра не тільки державних інформаційних систем, але і самих державних органів і їхніх послуг, навіть якщо вони надаються традиційним (неелектронним) способом.

На малюнку 14 наведена технічна модель інтеграції відомчих інформаційних систем на основі веб-служб XML. При цьому інтеграційний шлюз може забезпечувати не тільки маршрутизацію повідомлень (брокер повідомлень), але і реалізовувати функції колективного UDDI-регістра доступних державних інформаційних систем, а також реалізовувати функції „брокера веб-служб“, тобто забезпечувати механізм взаємодії між відомчими інформаційними системами як веб-службами.

Microsoft .NET як платформа інтеграції

Чому для проекту створення Урядового шлюзу у Великобританії, аналогічних проектів у Данії і ряді інших країн в якості партнера держави обрали Microsoft і її технології? Коротка відповідь така. Тому що Microsoft сформулювала досить передову концепцію архітектури інформаційних систем під назвою .NET, яку можна визначити коротко в такий спосіб: „Microsoft .NET — це програмне забезпечення для інтеграції інформації, людей, систем і пристроїв на основі технологій XML і веб-служб“.

Платформа Microsoft .NET надає інтегровані засоби розробки, що забезпечують створення додатків у вигляді веб-служб, а також серверні продукти, у яких забезпечена глибока підтримка стандартів XML і веб-служб з погляду інформаційного обміну.

Чому варто використовувати Microsoft BizTalk Server для реалізації архітектури й інфраструктури інтеграції

Основна причина полягає в тому, що BizTalk Server є саме таким сервером інтеграції додатків, що містить потужні графічні засоби проектування процесів інтеграції. Цей сервер підтримує:

маршрутизацію документів;
конвертацію документів у необхідну форму;
формалізацію ділових процедур;
„транзакційність“, тобто контроль за виконанням ділових операцій з інформацією і документами.

Тут варто відзначити масштабованість рішення, запропонованого корпорацією Microsoft для Центрального урядового порталу Великобританії:

5 млрд. звертань на рік;
500 транзакцій на секунду;
обмін 100 документами по 10 Кбайт в секунду;
готовність 365×7×24 (365 днів на рік, 7 днів на тиждень і 24 години на добу);
лінійний ріст продуктивності з додаванням обладнання;
підтримка механізму транзакцій (Transaction Engine, TE).

Архітектура Урядового шлюзу (на прикладі Великобританії)

Після обговорення основних аспектів використання XML і технології веб-служб можна вдатися до більш детального розгляду практичної реалізації Урядового шлюзу Великобританії.

Архітектура Урядового шлюзу включає наступні основні компоненти:

веб-вузли і портали окремих відомств;
автентифікація і реєстрація користувачів (Registration & Enrolment, R&E);
контроль транзакцій (Transaction Engine, Tx) і маршрутизація документів;
інтеграція і механізм правил на основі протоколу SOAP і стандарту UDDI;
сервери інтеграції відомства (Department Integration Services).

Тобто Урядовий шлюз у Великобританії взаємодіє не напряму з відомчими інформаційними системами, яких у країні близько 1800, а з серверами інтеграції рівня окремих відомств, що, у свою чергу, забезпечують інтеграцію і маршрутизацію інформації всередині організацій.

Основні функції Урядового шлюзу полягають у наступному:

швидке розгортання електронних послуг. Наприклад, модифікація вже існуючих систем міністерств і відомств, спрямована на розширення їхніх можливостей для масового надання послуг;
вільний, не жорсткий зв'язок між клієнтською (front-end) і серверною (back-end) частинами, що створює можливість для їхнього незалежного розвитку;
виключення дублювання технічних засобів і послуг, необхідних для забезпечення взаємодії окремих державних установ із громадянами по Інтернету;
створення основи для надання інтегрованих (joined-up) послуг шляхом централізації послуг автентифікації та організації взаємодії з багатьма державними структурами;
стимулювання того, щоб приватні компанії і державні організації розробляли власні додатки, що можуть взаємодіяти з інформаційними системами центральних органів влади на стандартній однаковій основі.

Мал. 5. Загальна схема архітектури Урядового шлюзу

Модель Урядового шлюзу включає наступні компоненти:

Об'єднані послуги автентифікації та авторизації для державних органів, що дає користувачам можливість працювати з будь-якими інформаційними системами відповідних організацій по Інтернету в захищеному режимі, на основі використання єдиного набору сертифікатів за допомогою будь-якого пристрою, у будь-якому місці і в будь-який час;
Простий засіб створення веб-форм, призначених для подачі документів. Надає розроблювачам програмного забезпечення єдині механізми, що дозволяють здійснювати передачу даних в урядовий портал;
Крім створення механізмів для вхідних документів, Шлюз створює умови для міжвідомчої взаємодії і комунікацій. Фактично він працює як брокер повідомлень, що маршрутизує документи їхнім одержувачам, одночасно трансформуючи їх у формат приймаючих систем;
Єдиний механізм правил, що реалізований у вигляді веб-служб і надає правила обробки документу, доступні для всіх систем. Він відповідає за перевірку правильності полів, відповідність схемам документів і бізнес-правилам. За допомогою даного механізму забезпечується однакове використання у всіх інформаційних системах тих же самих правил перевірки на відповідність;
Створення основи для надання послуг на базі „життєвих епізодів“. Шлюз пропонує всім сторонам, залученим до процесу надання інформації і послуг, відповідний інтерфейс. Тому приватній особі чи компанії буде потрібно один-єдиний раз ввести свої дані, після чого можна бути впевненим в тому, що всі зацікавлені сторони одержать цю інформацію. Наприклад, при створенні нової компанії необхідно лише раз відправити через єдиний інтерфейс по суті ту ж саму інформацію в податкову інспекцію, реєстраційну палату та інші державні органи;
Урядовий шлюз реалізує архітектуру, яку можна охарактеризувати як „слабко зв'язана інтеграція“ між клієнтськими системами, де вводяться форми, і серверними системами. Так, веб-форми можуть згодом змінюватися, ставати більш складними з метою розширення їхніх функціональних можливостей, а також надаватися все новим і новим державній структурам по мірі їхнього підключення до онлайнових систем. Серверні системи можуть бути модернізовані чи змінені, що не має ніякого впливу на веб-форми. За допомогою цієї слабко зв'язаної моделі окремі державні організації зможуть використовувати раніше зроблені інвестиції, зберегти існуючі системи і навички персоналу, а також удосконалювати свої системи в міру розвитку логіки бізнесу;
Реалізація єдиної структури для створення послуг, управління ними і їхньою підтримкою, що включає засоби, які співтовариство професіоналів може застосовувати для публікації, коментування, зміни схем і документів. Завдяки цьому всі сторони мають загальну інформаційну базу і залучені до єдиного процесу.

Основні принципи проектування Урядового шлюзу у Великобританії полягали в наступному:

максимальне використання стандартних комерційних продуктів;
покомпонентна розробка, що включає локалізацію функціональних можливостей у незалежних послугах із стандартними інтерфейсами між ними;
опора на промислові стандарти;
мережні протоколи TCP/IP, HTTP;
інтерфейси (Com+, XML, SOAP);
СУБД (SQL Server, ADO, OLEDB і ODBC для доступу до даних);
засоби розробки (C#, Visual Basic, Visual C++, ATL, Transact SQL);
висока продуктивність;
масштабованість;
надійність;
гнучкість і розширюваність;
підтримка великої кількості мов (збереження стандартних елементів інтерфейсу в спеціальних базах даних).

Технічні елементи архітектури Урядового шлюзу

Ті, кого не цікавлять технічні питання реалізації архітектури Урядового шлюзу Великобританії, можуть пропустити цей підрозділ і відразу перейти до розділу „Стандарти і єдина архітектура інформаційних технологій для проектів електронного уряду і міжвідомчих проектів“.

Тут розглядаються деякі конкретні деталі кожної з чотирьох складових Урядового шлюзу:

веб-вузли і портали;
автентифікація і реєстрація;
транзакції;
сервери інтеграції відомства (DIS-Department Integration Server).

Веб-вузли і портали

Веб-вузли і портали служать систематизованими сховищами веб-форм, що можуть використовуватися громадянами і компаніями для надання інформації державним органам.

Мал. 6. Логічна архітектура урядового порталу

Портал надає структуру для всіх хостованих державою форм документів. Там також є загальна служба реєстрації і автентифікації (Registration and Enrollment Portal Authentication).

Підсистема роботи з формами використовує локальне програмне забезпечення проміжного шару, що забезпечує бізнес-функціональність. Можливе також використання веб-служб, що можуть містити загальнодоступні правила реалізації бизнес-логіки для окремих форм. Дані, що вводяться користувачем, зберігаються в базі даних порталу, і після того, як форма заповнена, ці дані використовуються для конструювання XML-документа, що пересилається в Шлюз. Формальне надання (відправлення) документа означає також те, що він відповідає опублікованим для Шлюзу протоколам, що реалізують взаємодію зі Шлюзом. Усі стани виконання транзакції, пов'язані з відправленням (збереженням) документу, також відслідковуються в базі даних порталу.

Форми і перевірки на коректність

Служба форм працює з електронними версіями існуючих паперових бланків. Ці форми можуть відповідати сценарію „Життєві епізоди“, коли одразу декілька державних відомств повинні бути проінформовані про одну й ту ж саму дію громадянина. Наприклад, при реєстрації нової компанії користувач заповнює єдину форму, інформація з який передається в податкову інспекцію, реєстраційну палату тощо.

Технічно ці форми можуть бути представлені як ASP-сторінки або ASP .NET-сторінки, що реалізують логіку за допомогою компонентів проміжного шару на основі COM+ або .NET-служб.

При використанні веб-служб для окремих форм проміжний шар може перенаправляти туди запити. Це створює рівень абстракції, що забезпечує велику гнучкість.

Передача брокеру повідомлень

Після заповнення форми користувач пересилає дані в Шлюз. Дії, виконувані системою, залежать від способу реєстрації користувача: чи використовує він тільки ім'я та пароль або сертифікат.

Ім'я і пароль. Коли користувач вирішив передати дані, компонент бізнес-служби (логіки) на сервері конструює XML-документ, що відповідає опублікованій схемі. Зокрема, заголовок документу містить у собі заповнені поля імені і пароля користувача. Після цього XML-документ через безпечне HTTPS-з'єднання передається на приймаючу ASP-сторінку Шлюзу, де компонент авторизації і реєстрації (R&E-Registration and Enrollment Service) перевіряє права і відповідним чином маршрутизує документ.

Сертифікат. Коли користувач вирішив передати дані, компонент бізнес-служби (логіки) на сервері конструює XML-документ, що відповідає опублікованій схемі. Але в цьому випадку документ пересилається назад веб-оглядачу, де клієнт підключить сертифікат (Private Key, секретний ключ) до специфічних секцій документа і відішле його назад на сервер. Після цього сервер через HTTPS-з'єднання перешле документ на Шлюз, що за допомогою відкритого ключа, отриманого від авторизованого сертифікаційного центра (відправленого разом з документом), перевірить сертифікат і відповідним чином маршрутизує документ.

Веб-служби механізму реалізації правил

Механізм правил надає порталу і серверам інтеграції відомства загальний механізм для перевірки або документу в цілому, або окремих його полів, що теж можливо.

Поширення протоколу SOAP і можливість реалізації SOAP у Microsoft Visual Studio зробило технології веб-служб реальністю. Тепер такі функції, як перевірка форм, можуть здійснюватися по Інтернету, що раніше, як правило, робилося локально. Це дозволить державним клієнтським і серверним системам, а також третім сторонам використовувати загальний набір служб, забезпечуючи більш високий рівень відповідності і гарантію того, що посланий через веб-вузол документ буде прийнятий відомством, для якого він призначається. Це також означає, що якщо змінюється яке-небудь бізнес-правило, то будучи реалізованим як веб-служба, воно одразу ж стає доступним для всіх систем і буде однаково ними використовуватися.

Інтерфейс веб-служб реалізується на основі протоколу SOAP.

Брокер повідомлень і автентифікації

Брокер повідомлень і автентифікації містить дві підсистеми:

реєстрація і авторизація (Registration and Enrollment, R&E);
механізм транзакцій (Transaction Engine, TE).

Мал. 7. Високорівневий погляд на інфраструктуру механізму тразакцій

Підсистема реєстрації і авторизації обслуговує користувачів, що підписалися на послугу, і виконує функцію автентифікації. Механізм транзакцій використовує цю підсистему для автентифікації прийнятих документів, а також керує надійною маршрутизацією документів у відповідні серверні системи. Нижче наводиться більш детальний опис брокера повідомлень. Реєстрація і Авторизація. Ця підсистема керує процесом реєстрації засвідчених документів у Шлюзі, перевіркою введеної інформації на основі даних, представлених серверними системами, підпискою на послуги і поточним управлінням даними про реєстрацію і підписках на послуги.

Механізм транзакцій є головною точкою входу для транзакцій, що повинні виконуватися різними державними структурами. Ці транзакції можуть бути підготовлені клієнтами або шляхом взаємодії на основі веб-оглядача з відомчими чи іншими веб-вузлами, або за допомогою додатків, встановлених на клієнтських машинах. У будь-якому випадку, цілком підготовлена транзакція може бути обладнана цифровим підписом і відправлена на Урядовий шлюз по Інтернету у вигляді форматованого XML-документу, що пересилається по HTTP. Після цього механізм транзакцій перевіряє цілісність отриманого підписаного запиту, викликає службу реєстрації і авторизації для перевірки використаних сертифікатів і підтвердження того, що клієнт має право на запитану транзакцію. Після цього транзакція пересилається на обробку відповідній серверній системі.

Надійна доставка і черги очікування. Відправлення повідомлення на сервер інтеграції відомства (DIS), як правило, здійснюється через інтранет-мережу, яка за замовчуванням не підтримує механізм гарантованої доставки. Відповідно, механізм транзакцій може використовувати систему гарантованої доставки повідомлень, надану сервером BizTalk Server. BizTalk-сервер, що відправляє, пересилає на сервер інтеграції відомства документ (як надійне повідомлення BizTalk Server) і зберігає його копію у своїй черзі на випадок повторного пересилання. BizTalk-сервер на приймаючій стороні сервера інтеграції відомства після одержання повідомлення через посилання URL всередині документу пересилає підтвердження на BizTalk-сервер, що відправив повідомлення. При цьому сервер, що відправив повідомлення, видаляє його зі своєї черги можливого повторного відправлення. У випадку, якщо відправляючий BizTalk-сервер не одержав підтвердження, він спробує переслати його повторно певну кількість разів доти, поки він буде успішно отриманий приймаючим BizTalk-сервером, або поки не вичерпається ліміт кількості спроб. У цьому випадку повідомлення буде поміщено в чергу проблемних повідомлень для відповідної наступної обробки.

Мал. 8. Системи віддалених державних відомств

Це є одним із прикладів того, як повідомлення може потрапити в чергу проблемних повідомлень. Документ може також потрапити туди, якщо він не пройде перевірку на безпеку. Механізм транзакцій періодично виконує необхідні роботи по обробці таких проблемних повідомлень.

Сервери інтеграції відомства (DIS) забезпечують з'єднання і двосторонні комунікації між Урядовим шлюзом і системами окремих відомств. Додаткова перевага, одержувана завдяки наявності такого рівня в архітектурі, полягає в тому, що при цьому зменшується кількість серверних систем, з якими брокер повідомлень Урядового шлюзу був би змушений зв'язуватися напряму. Брокер повідомлень взаємодіє з окремими відомствами на рівні серверів інтеграції відомства, що, у свою чергу, забезпечують інтеграцію з різними прикладними серверними системами конкретного відомства. У таких широкомасштабних проектах, як Урядовий шлюз у Великобританії, існує близько 1800 різних прикладних систем у різних департаментах, і такий підхід істотно спрощує роботу брокера повідомлень. Сервер інтеграції відомства одержує документ на свою ASP-сторінку від механізму транзакцій через систему гарантованої доставки повідомлень BizTalk-сервера. Далі він або пересилає документ без змін відповідній прикладній системі, використовуючи стандартний або спеціально написаний компонент інтеграції додатків (Application Integration Component, AIC) BizTalk-сервера, або використовує засоби мапування і трансляції для конвертації документа таким чином, щоб задовольнити специфікаціям приймаючої сторони. Наприклад, він може змінювати довжину полів до використання AIC-компонента для остаточної передачі документа приймаючій стороні.