Що таке tModel в UDDI?, Інші СУБД, Бази даних, статті

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


У даній статті описується три різні сфери застосування tModel в UDDI.


Використання tModel для подання інтерфейсів


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


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


У використанні UDDI є одна явна особливість: коли провайдер сервісу бажає зареєструвати сервіс в UDDI, він не тільки повинен гарантувати реалізацію інтерфейсу, а більше того, він повинен гарантувати реалізацію інтерфейсу, вже зареєстрованого в UDDI (!).


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


Звичайно може бути і так, що сервіс, який хоче опублікувати його провайдер, не реалізує стандартний інтерфейс. В цьому випадку провайдер в першу чергу повинен зареєструвати в UDDI свій нестандартний інтерфейс, а після цього зареєструвати вже сервіс, його реалізує. На даний момент вже можна з упевненістю сказати, що поняття інтерфейсу дуже важливо для UDDI. Але як представлений інтерфейс в UDDI? На якій мові описується інтервейс в реєстрі? Відповідь дає нам першу важливу роль tModel: кожен окремий екземпляр інтерфейсу описується в UDDI через tModel.


Наведемо відповідний приклад. Уявімо, що ми хочемо реалізувати сервіс для soadesign.ru, який приймає в якості вхідного параметра рядок, що відображає ім’я користувача, а в якості відповіді повертає невід’ємне ціле число, що відображає кількість написаних користувачем статей на сайті. Це схоже на дуже специфічний (нестандартний) сервіс, тобто ми навряд чи можемо знайти вже опублікований сервіс, який ми б могли реалізувати. В цьому випадку спочатку нам необхідно зареєструвати свій інтерфейс.


Використовуючи відповідні кошти, ми створюємо і реєструємо в UDDI бажаний нами сервіс – це всього лише tModel, що виглядає наступним чином:

<tModel tModelKey=”uuid:5DD52389-B1A4-4fe7-B131-0F8EF73FF175″>
<name>this is the interface we created
<description xml:lang=”en”>interface for Web service answering num of submissions
<overviewDoc>
<description xml:lang=”en” The service”s WSDL document
<overviewURL>http://soadesign.ru/services/interfaces/numOfSubmissions.wsdl
</overviewDoc>
</tModel>

Це – tModel, яка відображає інтерфейс сервісу, який ми збираємося реалізувати і зареєструвати. Тут варто звернути увагу на кілька моментів. По-перше, це опис має UUID, який генерується автоматично при реєстрації і є глобально-унікальним ідентифікатором, який можна використовувати в посиланнях на цю tModel. По-друге, реальне визначення інтерфейсу (WSDL) лежить за посиланням, зазначеної в теге overviewURL. Насправді тут можна зареєструвати посилання на будь-який документ з описом інтерфейсу, але на практиці посилання на WSDL найбільш відповідний варіант для даного випадку.


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


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


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

У реальному житті можливо, що для потрібного нам сервісу ми вже знаємо яка компанія (businessEntity) його реалізувала. Таким чином на основі цих знань і використовуючи UDDI-API ми можемо знайти первинний для нашого пошуку елемент businessEntity, а звідти ми вже зможемо знайти запис про інтерфейс, яка нас і призведе до WSDL-документу. У той же час в більшості випадків ми знаємо лише якого типу сервіс нам потрібен і ми поняття не маємо яка компанія могла б його реалізувати. Для даного випадку більш підходящої буде наступна стратегія пошуку: спочатку необхідно знайти інтерфейс, який реалізує потрібну функціональність, далі для знайденого інтерфейсу (ів) ми можемо знайти всі компанії, які реалізували сервіс для даної tModel.


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


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


 





Розстрочка на програмні продукти Oracle в “Інтерфейс” У компанії “Інтерфейс” діє нова програма корпорації Oracle по фінансуванню придбання ліцензій клієнтами, що перебувають в країнах СНД (Oracle Financing). Мета програми – надання розстрочки платежу при придбанні програмного забезпечення (ПО) і послуг корпорації Oracle у випадках, коли сума контракту становить не менше $ 100,000.


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


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


Використання tModel як засобу категоризації UDDI


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


Якщо піти наприклад на сайт www.uddi.org, то там можна знайти “UDDI Core tModels” – Це набір визначених tModel, що відображають класифікаційну інформацію. Наприклад, там є tModel з ідентифікатором “uuid: C1ACF26D-9672-4404-9D70-39B756E62AB4” і ім’ям “wsdlSpec”. Це спеціальна категоріальна tModel, яка використовується з визначеннями інтерфейсів, подібних приведеному вище.


Звернемося до нашого прикладу. У нас є інтерфейс, визначений через WSDL, і ми хочемо категоризувати його використовуючи tModel “wsdlSpec”. Зробивши так, ми дозволимо UDDI процесору зрозуміти, що наш інтерфейс визначається через WSDL.

<tModel tModelKey=”uuid:5DD52389-B1A4-4fe7-B131-0F8EF73FF175″>
<name>this is the interface we created
<description xml:lang=”en”>interface for Web service answering num of submissions
<overviewDoc>
<description xml:lang=”en” The service”s WSDL document
<overviewURL>http://soadesign.ru/services/interfaces/numOfSubmissions.wsdl
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey=”uuid:c1acf26d-9672-4404-9d70-39b756e62ab4″
keyName=”Specification for a web service described in WSDL”
keyValue=”wsdlSpec”/>
</categoryBag>
</tModel>

Дивлячись на наведений приклад, можна помітити, що додана категорізующая інформація поміщена в елемент “categoryBag”, що використовує структуру “keyedReference”. Такий синтакс додавання классифицирующей інформації в інтерфейс.


Тепер, коли якийсь розробник буде шукати через UDDI API “wsdlSpec”, наш інтерфейс потрапить в результат пошуку. Після цього розробник може більш детально вивчити – на скільки функціонал нашого інтерфейсу задовольняє його потреби.


Природно подібний пошук може видати величезну кількість визначень інтерфейсів, тому потрібні додати додаткову класифікацію, щоб зробити пошук більш ефективним. Звернімося ще раз до даного документу “UDDI Core tModels” і знайдемо tModel з ідентифікатором “uuid: c0b9fe13-179f-413d-8a5b-5004db8e5bb2” іменовану “On-Line Information Services”. Оскільки наш сервіс дійсно є on-line сервісом, ми можемо додати дану категоризаційної інформацію в наш інтерфейс.

<tModel tModelKey=”uuid:5DD52389-B1A4-4fe7-B131-0F8EF73FF175″>
<name>this is the interface we created
<description xml:lang=”en”>interface for Web service answering num of submissions
<overviewDoc>
<description xml:lang=”en” The service”s WSDL document
http://soadesign.ru/services/interfaces/numOfSubmissions.wsdl
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey=”uuid:c1acf26d-9672-4404-9d70-39b756e62ab4″
keyName=”Specification for a web service described in WSDL”
keyValue=”wsdlSpec”/>
<keyedReference
tModelKey=”uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2″
keyName=”On-Line Information Services”
keyValue=”514191″/>
</categoryBag>
</tModel>

Після проведення подібних дій опис нашого інтерфейсу все більш і більш наближається до завершеного вигляду.


Використання tModel як “простір імен”


Уявімо тепер, що розробник провівши пошук знайшов-таки наш інтерфейс. Для прийняття рішення про використання далі йому необхідно буде звернутися до WSDL-документу, оскільки вивчаючи лише UDDI-запис ми не можемо прийняти рішення через обмеженість інформації. Звідси випливає питання – чи можемо ми доповнити реєстраційну запис інтерфейсу всією інформацією, необхідної для прийняття рішення?


Для початку ми хотіли б додати інформацію про необхідні параметри виклику сервісу і можливий результат запиту. Реалізувати цю ідею також можна через додавання структури “keyedReference” в елемент “categoryBag”.

<tModel tModelKey=”uuid:5DD52389-B1A4-4fe7-B131-0F8EF73FF175″>
<name>this is the interface we created
<description xml:lang=”en”>interface for Web service answering num of submissions
<overviewDoc>
<description xml:lang=”en” The service”s WSDL document
<overviewURL>http://soadesign.ru/services/interfaces/numOfSubmissions.wsdl
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey=”uuid:c1acf26d-9672-4404-9d70-39b756e62ab4″
keyName=”Specification for a web service described in WSDL”
keyValue=”wsdlSpec”/>
<keyedReference
tModelKey=”uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2″
keyName=”On-Line Information Services”
keyValue=”514191″/>
<keyedReference
keyName=”input”
keyValue=”xsd:string”/>
<keyedReference
keyName=”output”
keyValue=”xsd:integer”/>
</categoryBag>
</tModel>

На практиці тут виникає одна істотна проблема: різні розробники навіть однієї компанії норовлять використовувати різні імена – “input”, “myInput” або навіть “input-0”. Те ж може статися і в відношенні “output”.


Із за відсутності єдиної системи іменування користувачам реєстру дана інформація стає марна, так як нею стає неможливо користуватися – іи не знаємо ключа за яким здійснювати пошук.


Як же вирішити цю проблему? Тут також можна використовувати tModel. Для цього треба створити (зареєструвати в UDDI) “input_tModel”:

<tModel tModelKey=”uuid:E27972D8-717F-4516-A82D-B688DC70170C”>
<name>input_tModel
<description xml:lang=”en”>namespace of input_tModel
<overviewDoc>
<description xml:lang=”en”>whatever description you want
<overviewURL>http://soadesign.ru/internalDocuments/inputDetails.html
</overviewDoc>
</tModel>

Після створення “input_tModel” та реєстрації її в UDDI (те ж стосується і “output_tModel”) можна буде вже не хвилюватися про відсутність системи іменування – тепер в описі інтерфейсу можна використовувати посилання на зумовлені структури.

<tModel tModelKey=”uuid:5DD52389-B1A4-4fe7-B131-0F8EF73FF175″>
<name>this is the interface we created
<description xml:lang=”en”>interface for Web service answering num of submissions
<overviewDoc>
<description xml:lang=”en” The service”s WSDL document
<overviewURL>http://soadesign.ru/services/interfaces/numOfSubmissions.wsdl
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey=”uuid:c1acf26d-9672-4404-9d70-39b756e62ab4″
keyName=”Specification for a web service described in WSDL”
keyValue=”wsdlSpec”/>
<keyedReference
tModelKey=”uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2″
keyName=”On-Line Information Services”
keyValue=”514191″/>
<keyedReference
tModelKey=”uuid:E27972D8-717F-4516-A82D-B677DC70170C”
keyName=”whatever-input-name”
keyValue=”xsd:string”/>
<keyedReference
tModelKey=”uuid:E27972D8-717F-4516-A82D-B6483C70170C”
keyName=”whatever-output-name”
keyValue=”xsd:integer”/>
</categoryBag>
</tModel>

Дане використання “input_tModel” нагадує використання просторів імен в XML: група розробників тепер має єдину концепцію для вхідних параметрів (а так само для вихідних результатів). Даний підхід має дуже великий селективністю і дозволяє істотно скоротити число повертаються результатів на запит до UDDI (в межі до одного).

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


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

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

Ваш отзыв

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

*

*