Методи роботи з моделлю майстер-даних в SOA-проектах

Автор: Bладімір Енгельс, Oracle СНД


Що таке модель майстер-даних


Серед усієї сукупності даних, що використовуються в компаніях, є певна специфічна категорія (15-20% від усього обсягу), яка використовується як "мова бізнесу", що лежить в основі самого бізнесу компанії. Такі дані називають майстер-даними. Саме самі ці дані є цінністю для бізнесу, а не кошти управління ними (наприклад, програмно-апаратна інфраструктура). Метою даної статті є розмова про майстер-даних з змістовної точки зору, а не як про "придатку" до забезпечує інфраструктурі.


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


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

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

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


Канонічна модель майстер-даних


Канонічна модель даних – Це версія моделі майстер-даних, незалежна від додатків і прикладних систем підприємства.

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


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


Існує безліч спроб в різних галузях виробити стандарт на представлення бізнес-даних, які знаходяться на різній стадії завершення. Наприклад, під час розквіту ідей по електронній комерції компанія ComerceOne зробила популярним формат xCBL, компанія Ariba просувала формат cbXML, а RosettaNet використовувала Partner Interface Processes (PiP). У фінансовій сфері часто використовуються формати FIX та SWIFT, а в охороні здоров'я – HIPPA і HL7.

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

В якості основного засобу підтримки канонічних моделей майстер-даних в SOA-рішеннях можуть використовуватися інструмен класу Enterprise Service Bus (ESB), а саме такі інструменти продукту Oracle ESB:


Моделі майстер-даних у формі XML і її розширення

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

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


  1. розширення типів шляхом успадкування або довизначення необов'язковими типами;
  2. використання версійність моделі даних.

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


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


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


.

Як же працює розширення типів шляхом успадкування або довизначення необов'язковими типами? XML дозволяє розширювати існуючі типи даних


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

Приклад 1. Наприклад, Ви вирішили підвищити ефективність обробки певних замовлень. Для цього Ви можете ввести в тип даних "інформація про замовлення" необов'язковий параметр "рівень обслуговування":

<ShipInfo serviceLevel=”high”>

</ShipInfo>

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

Приклад 2. Для того щоб ще більше підвищити ефективність обробки певних замовлень за межами Ваших бізнес процесів, Ви можете для замовлень, що відправляються в США, до обов'язкових п'яти цифр індексу вказати додаткові чотири цифри. Тоді поштова служба зможе більш точно маршрутизувати замовлення кінцевого одержувача. Для цього можна розширити тип "поштовий індекс" необов'язковим полем:

<ShipInfo>

<Address>

<PostalCode>
01234
<PCExt>5678</PCExt>
</PostalCode>
</Address>
</ShipInfo>

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

Може здатися, що система, в якій відсутність інформації не є помилкою, погано спроектована. Але це абсолютно не так, до тих пір, поки Ви на рівні моделі закріплюєте необов'язковість даних з точки зору бізнесу (наприклад, засобами XMLSchema).

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


Використання просторів імен

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*