Автор: Владимир Энгельс, 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-документ, который содержит всю необходимую информацию для обращения к сервису.
Все это звучит хорошо, за исключением одного момента: как приложение найдет необходимый элемент < businessTemplate ? Поскольку элемент businessTemplate является дочерним элементом businessTemplate, вопрос можно переформулировать "как приложение или разработчик найдет необходимый элемент businessEntity ?"
В реальной жизни возможно, что для нужного нам сервиса мы уже знаем какая компания (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 (в пределе до одного).