OASIS UDDI Specifications Technical Committeeは、WebサービスをWSDL記述でモデル化するためのUDDIを使用したアプローチについて記載した新しいテクニカルノートを公開いたしました。これは、難易度が高かった以前の方法から著しい進歩です。

この記事は、UDDIでWSDLをモデル化する新しいアプローチを検討し、その新しいアプローチでアプリケーションを作成する方法を提供するシリーズの第1回目です。今回は、新しいテクニカルノートの背景を説明し、続けてアプローチ法を説明していきします。この記事の読者はWSDL 1.1およびUDDI V2に精通していることを想定しています。

第2回では、UDDIモデルに対して行うことができる照会について検討する予定です。

第3回では、UDDIエンティティーを公開する方法、テクニカルノートに記載されている照会を構築する方法といったテクニカルノートより複雑な例を、スクリーン・ショットを交えて説明する予定です。

最終回では、UDDIへモデルを公開したり、UDDI4Jを使用して照会発行が可能なJava™アプリケーションの構築方法について説明する予定です。

テクニカルノートとは何か？

テクニカルノートは、UDDIレジストリーを使用する方法のガイダンスを提供しているOASIS UDDI Specifications Technical Committeeによって公開されたドキュメントです。テクニカルノートに記載されたアプローチを実装し確立すれば、それはベストプラクティスの候補になります。

上に戻る

なぜ新しいテクニカルノートが必要なのか？

WSDLとUDDIを使用した既存のベストプラクティスがスコープで制限され、WSDL bindingに重点を置いている一方で、JAX-RPCのようなWebサービスのプログラミング・モデルはWSDL portTypeに重点を置いています。

既存のベストプラクティスは、WSDL記述に関連するtModelを見つけ出すといった非常に単純な照会以外はサポートしていません。複合的な照会を発行するわけではないので、汎用的な情報は見つけ出されません。

既存のベストプラクティスはWSDLのservice要素やport要素に関しては網羅していませんでした。これはportTypeあるいはbindingの実装を検出する標準の方法がなかったということです。

上に戻る

新しいテクニカルノートの目的

新しいテクニカルノートの目的は以下のとおりです。

1. UDDIでWSDL portTypeのモデル化をサポートする。
2. Version1のベストプラクティスと互換性をもつ方法で、UDDIでWSDL bindingのモデル化をサポートする。
3. 特定のportTypeおよび、またはbindingの実装を照会が検索できるよう、WSDL serviceおよびWSDL portのモデル化をサポートする。
4. UDDI V2 APIあるいはUDDI V3 APIのいずれかによって操作された際、一貫したモデルを提供する。
5. WSDL記述の論理的あるいは物理的な構造や、portType、個々のファイル、リソースなどをサポートする。
6. 情報が重複していないWSDL記述から重要な情報を取得する。
7. モデルに対して正確で柔軟なUDDI照会をサポートする。

上に戻る

新しい標準tModel

テクニカルノートでは、記載されているアプローチをサポートするために、UDDIレジストリーによって提供されている9つの新しいtModelを紹介しています。これらのtModelのうちの6つは新しいカテゴリー・システムに相当し、残りの3つは標準のtModelです。ここでは6つの新しいtModelについて説明いたします。

新しいカテゴリー・システム

テクニカルノートではカテゴリー化を活用して、6つの新しいカテゴリー・システムを紹介しています。

1. WSDL Entity Type Category System
2. XML Namespace Category System
3. XML Local Name Category System
4. WSDL portType Reference Category System
5. Protocol Category System
6. Transport Category System

これらの新しいカテゴリー・システムの詳細は以下のとおりです。

WSDL Entity Type Category System
このカテゴリー・システムはWSDLエンティティーに相当するUDDIエンティティーの識別に使用されます。現在次のUDDIエンティティーで使用されています。

1. tModels
2. businessServices

WSDLではportTypeとbindingは同じ名前を持つことができるので、このカテゴリー・システムを使用するkeyedReferenceは、bindingに関係しているtModelとportTypeに関係しているtModelを識別するただ一つの方法です。

XML Namespace Category System
名前から分かるように、このカテゴリー・システムはWSDLに関連するネームスペースではなく、XMLネームスペースを表すために使用されます。これは最初に必要となるコンテキストではありますが、任意のXMLベースのモデリング・アプローチにも使用することができるので、WSDL テクニカルノートに定義されています。エンティティーのXMLネームスペースをキャプチャーすることで、照会にネームスペース名およびローカル名の両方から成る完全なXMLエンティティー名を使用することができます。

XML Local Name Category System
このXMLカテゴリー・システムは、UDDIエンティティーの名前がXML要素のローカル名と同じでない場合、ローカル名を保持するために一般的に使用されます。

WSDL portType Reference Category System
このカテゴリー・システムは、カテゴリー・システムに関係するkeyedReferenceのkeyValue属性値としてキーを格納することで、1つのUDDIエンティティーが別のUDDIエンティティーを参照することができるbindingとportType間のリンクを表わすために使用されます。

Protocol Category System
このカテゴリー・システムにより、ユーザー定義のプロトコルtModelが、テクニカルノートに記載されたアプローチに組み込まれるようになります。

Transport Category System
このカテゴリー・システムにより、ユーザー定義のトランスポートtModelsが、テクニカルノートに記載されたアプローチに組み込まれるようになります。

他の新しいtModel

テクニカルノートはさらにいくつかの標準tModelを紹介しています。それらを次に紹介いたします。

SOAP Protocol tModel
このtModelはWSDL SOAP bindingの使用を表わしています。

HTTP Protocol tModel
このtModelはWSDL HTTP bindingの使用を表わしています。これがSOAP/HTTP bindingの使用を表わすSOAP protocol tModelと共に使用されるHTTP transport tModelとは異なるtModelであることに注意してください。

WSDL Address tModel
WSDL実装ドキュメントが使用される場合、このtModelが使用されます。

上に戻る

UDDIでWSDL記述をモデル化する方法

このセクションでは、テクニカルノートに定義されているアプローチについて説明します。WSDLエンティティーのそれぞれのモデルについても説明いたします。ここでは、UDDI V2 APIおよびデータ構造仕様の点から説明いたしますが、UDDI V3モデルでもほとんど違いはありません。詳細はテクニカルノートを参照してください。

WSDL portType

WSDL portTypeはUDDIのtModelとして表されます。このtModelは、他のタイプのtModelと区別するためにWSDL portType　tModelとして上で説明したWSDL Entity Type Category Systemを使用して分類されます。

portType　tModelの名前はportTypeの名称です。これは、tModel名はURIとしてフォーマットされるべきであるというUDDIデータ構造仕様に反しています。tModel名用に考慮されたオプションは次のとおりでした。

1. portType名を使用する。これは選択オプションです。
2. portType名とネームスペース名を組合せて使用する。
3. 別のURIを使用して、tModelのcategoryBagのローカル名とネームスペース名を指定する。.

オプション2では、ネームスペース名あるいはportType名のどちらかでは検索が困難かもしれません。オプション3では、portType名では検索が困難であり、tModel名で表される情報がありません。オプション2とオプション3は組み合わせることができますが、ネームスペース名とportType名の両方が、tModel名の一部としてまたcategoryBagとして、2度格納されることになり、重複データとなってしまう可能性があります。

portTypeのネームスペースはportType tModelのcategoryBagにおけるkeyedReferenceで表わされます。このkeyedReferenceはXML Namespace Category Systemに関係しています。

メッセージ、オペレーションなどに関係するportTypeの詳細情報はUDDIでは複製されないので、portType　tModelはWSDLドキュメントを参照しなければなりません。このWSDLドキュメントには、portTypeからプログラミング言語インターフェースを生成するアプリケーション開発ツールや、portTypeの定義に対するリクエストを有効にする高機能なシステムといった情報を必要とするツールが、WSDLドキュメントを検索することができるようにportTypeが定義されています。tModelのoverviewURLはこのWSDLドキュメント用のURLを保持するために使用されています。

WSDL binding

WSDL bindingはUDDIのtModelで表わされます。このtModelは他のタイプのtModelと区別をするために、WSDL binding　tModelとして分類されています。この分類は、portTypeのtModelと同じカテゴリー・システムを使用していますが、binding　tModelとportType　tModelを区別する異なるkeyValueを持っています。

binding　tModelの名前はbindingの名称です。portType　tModelの名前に関係する上のオプションは、binding　tModelsでも適用でき、同じアプローチをとることができます。

bindingのネームスペースはbinding tModelのcategoryBagにおけるkeyedReferenceで表わされます。このkeyedReferenceは、XMLネームスペース名を保持する目的でテクニカルノートに定義された別の新たなカテゴリー・システムに関係します。

ドキュメント/リテラルなどに関係するbindingの詳細情報は、UDDIで複製されないので、binding tModelは、この情報を必要とするツールがWSDLドキュメントを検索することができるようにbindingが定義されているWSDLドキュメントを参照しなければなりません。tModel overviewURLはこのWSDLドキュメント用のURLを保持するために使用されます。

関係するbindingとportTypeのリンクは、binding tModelのcategoryBagにおける別のkeyedReferenceで表わされます。このkeyedReferenceのtModelKeyの値は、他のtModelのキー(特にportType tModel)の有効な値を持っているカテゴリー・システムを表わす新しい標準tModelのキーです。keyedReferenceのkeyValueの値は、bindingが関係するportTypeに相当するportType tModelのキーです。

bindingが表わすプロトコルはbinding tModelのcategoryBagにおける別のkeyedReferenceで表わされます。このkeyedReferenceのtModelKeyの値は、他のtModelのキー(特にプロトコルtModel)の有効な値を持っているカテゴリー・システムを表わす新しい標準tModelのキーです。keyedReferenceのkeyValueの値は適切なプロトコルtModelのキーです。SOAP/HTTPのよくある例では、新しいSOAPプロトコル tModelはテクニカルノートに定義され、このtModelのキーが使用されます。他のプロトコル tModelは公開することができるので、それらはこの新しいカテゴリー・システムで自動的に有効となります。

bindingがプロトコルに加えトランスポートも表わす場合、トランスポート情報を表わすために同様のアプローチがなされます。transport tModelのキーが有効な値を持つテクニカルノートに定義された別の新しい標準tModelがあります。また、このカテゴリー・システムに関係するkeyedReferenceは、binding tModelに加えられます。SOAP/HTTPのよくある例では、標準HTTPトランスポートtModelが使用されます。他のtransport tModelはUDDIで定義されることができ、それらはこのカテゴリー・システムで自動的に有効となります。

バージョン1のベストプラクティスとの互換性に関しては、binding tModelはwsdlSpecを使用して分類されるべきです。

WSDL service

WSDL serviceはUDDIのbusinessServiceで表わされます。WSDL serviceが既存のサービス用のWebサービス・インタフェースを表わす場合、既存のUDDI businessServiceが適切かもしれません。その場合には、WSDL情報はその既存のサービスに追加されることができます。適切な既存のサービスがない場合は、新しいUDDI businessServiceを作成することができます。

WSDL serviceとそのportを表わすには、2つのアプローチがあります。

1. WSDL serviceで使用される拡張要素がなく、各ポートの拡張要素のアドレスがUDDI accessPointとして表わすことができる場合、正常なアプローチは、サービスを含むWSDLファイルを参照せずに、UDDIでのサービスとそのポートからの情報をすべて表わすことです。
2. 上の正常なアプローチが不可能である場合、代わりのアプローチが定義されます。サービスを含むWSDLへの参照が保持され、WSDLドキュメントが情報を得るために検索されなければなりません。

WSDL port

WSDL portはUDDI bindingTemplateで表わされます。WSDL serviceとそのportの抑制関係は、UDDI businessServiceとそのbindingTemplatesの抑制関係とよく似ています。

上に戻る

まとめ

テクニカルノートに記載されているUDDIへWSDLをマッピングするアプローチは、図1のようにまとめることができます。

上に戻る

結論

今回は、UDDIとWSDLを使用して新しいテクニカルノートの背景について解説し、テクニカルノートに記載されたアプローチの要点について説明いたしました。

このシリーズの今後の記事では、今回紹介した新しいアプローチで可能となる照会について解説し、より複雑な例を提示し、テクニカルノートに従ってUDDIに公開するJavaアプリケーションを書く方法や、WSDLの新しいUDDIモデルに対する一般的な照会を発行する方法について説明をしていく予定です。

参考文献

• このシリーズの第2回の記事「 A new approach to UDDI and WSDL, Part 2」を参照してください。( developerWorks 、2003年9月)
  
  
• 「Understanding WSDL in a UDDI registry, Part 2」(developerWorks 、2001年9月)では、WSDLとUDDIを共に使用する以前のベストプラクティスに関係する様々なシナリオについて説明しています。
  
  
• 「Understanding WSDL in a UDDI registry, Part 3」(developerWorks 、2001年11月)では、WSDLとUDDIを共に使用する以前のベストプラクティスを実装しているJavaアプリケーションについて説明しています。
  
  
• OASIS OASIS UDDI Specifications Technical Committeeは、UDDIの標準化をを担っています。
  
  
• この記事は最新のテクニカルノートに基づいています。「Using WSDL in a UDDI Registry, Version 2.0」は、OASIS UDDI Specifications Technical Committeeによって公式にテクニカルノートとして公開されました。
  
  
• 以前のベストプラクティス「Using WSDL in a UDDI Registry, Version 1.08」は、今までのdeveloperWorks記事が書かれて以来、OASIS UDDI Specifications Technical Committeeによって更新されています。
  
  

著者について

John ColgraveはIBM WebSphere UDDI Registryの設計者であり、OASIS UDDI Specifications Technical Committeeのメンバーでもあります。彼は、UDDIとWSDLを使用した新たなOASIS UDDI テクニカルノートの著者の一人です。

この記事を評価する

コメント

上に戻る

目次

• テクニカルノートとは何か？
• なぜ新しいテクニカルノートが必要なのか？
• 新しいテクニカルノートの目的
• 新しい標準tModel
• UDDIでWSDL記述をモデル化する方法
• まとめ
• 結論
• 参考文献
• 著者について
• コメント