Red Hat Training
A Red Hat training course is available for JBoss Enterprise SOA Platform
JUDDI レジストリーガイド
これは、開発者にサービスレジストリーを使用するためのガイドです。
概要
はじめに
1. ドキュメント規則
1.1. 表記規則
等幅ボールド
現在の作業ディレクトリーのファイルmy_next_bestselling_novel
の内容を表示するには、シェルプロンプトで cat my_next_bestselling_novel コマンドを入力し、Enter を押してコマンドを実行します。
Enter を押してコマンドを実行します。Ctrl+Alt+F2 を押して、仮想ターミナルに切り替えます。
等幅ボールド
で示されます。以下に例を示します。
ファイル関連のクラスには、ファイルシステムのfilesystem
、ファイルのfile
、ディレクトリーのdir
が含まれます。各クラスには、独自の関連付けられたパーミッションセットがあります。
メインメニューバーから System → Preferences → Mouse を選択し、Mouse Preferences を起動します。Buttons タブで、Left-handed mouse チェックボックスを選択し、Close をクリックしてメインのマウスボタンを左から右に切り替えます (マウスを左手で使い易くします)。特殊文字を gedit ファイルに挿入するには、メインメニューバーから Applications → Accessories → Character Map を選択します。次に、Character Map メニューバーから Search → Find… を選択し、Search フィールドに文字の名前を入力して Next をクリックします。目的の文字が Character Table で強調表示されます。この強調表示した文字をダブルクリックして Text to copy フィールドに配置し、Copy ボタンをクリックします。ここでドキュメントに戻り、gedit メニューバーから Edit → Paste を選択します。
ssh を使用してリモートマシンに接続するには、シェルプロンプトで ssh username@domain.name を入力します。リモートマシンがexample.com
で、そのマシン上でのユーザー名が john の場合は、ssh john@example.com と入力します。mount -o remount file-system コマンドにより、指定したファイルシステムが再マウントされます。たとえば、/home
ファイルシステムを再マウントする場合、コマンドは mount -o remount /home となります。現在インストールされているパッケージのバージョンを表示するには、rpm -q package コマンドを使用します。これにより、package-version-release のような結果が返されます。
Publican は DocBook 公開システムです。
1.2. 引用規則
mono-spaced roman
に設定され、以下のように表示されます。
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
mono-spaced roman
に設定されますが、以下のように構文の強調表示が追加されます。
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm, struct kvm_assigned_pci_dev *assigned_dev) { int r = 0; struct kvm_assigned_dev_kernel *match; mutex_lock(&kvm->lock); match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head, assigned_dev->assigned_dev_id); if (!match) { printk(KERN_INFO "%s: device hasn't been assigned before, " "so cannot be deassigned\n", __func__); r = -EINVAL; goto out; } kvm_deassign_device(kvm, match); kvm_free_assigned_device(kvm, match); out: mutex_unlock(&kvm->lock); return r; }
1.3. 注記および警告
2. ヘルプの利用とフィードバック提供
2.1. ヘルプが必要ですか ?
- Red Hat 製品に関する技術サポート記事の知識ベースの検索または閲覧。
- Red Hat グローバルサポートサービス (GSS) へのサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
2.2. ご意見をお寄せください
第1章 はじめに
1.1. ビジネス統合
1.2. サービス指向アーキテクチャーとは
はじめに
SOA (Service Oriented Architecture) は単一のプログラムまたはテクノロジーではありません。ソフトウェア設計パラダイムと見なします。
1.3. サービス指向アーキテクチャーの重要なポイント
- 交換される メッセージ
- サービスリクエスターおよびプロバイダーとして動作する エージェント
- メッセージを送受信できるようにする 共有トランスポートメカニズム。
1.4. JBoss Enterprise SOA Platform とは
1.5. Service-Oriented Architecture Paradigm
- サービスプロバイダー
- サービスプロバイダーはサービスへのアクセスを許可し、サービスの説明を作成し、サービスブローカーに公開します。
- サービスリクエスター
- サービスリクエスターは、サービスブローカーが提供するサービスの説明を検索して、サービスを検出します。リクエスターはサービスプロバイダーが提供するサービスにバインドするロールも果たします。
- サービスブローカー
- サービスブローカーは、サービスの説明のレジストリーをホストします。リクエスターをサービスプロバイダーにリンクします。
1.6. コアおよびコンポーネント
1.7. JBoss Enterprise SOA Platform のコンポーネント
- 完全な Java EE 5 準拠のアプリケーションサーバー (JBoss Enterprise Application Platform)
- エンタープライズサービスバス (JBoss ESB)
- ビジネスプロセス管理システム (jBPM)
- ビジネスルールエンジン (JBoss ルール)
- オプションの JBoss Enterprise Data Services (EDS) 製品のサポート。
1.8. JBoss Enterprise SOA Platform の機能
- JBoss Enterprise Service Bus (ESB)
- ドメインはサービス間でメッセージを送信し、それらを変換して、異なるタイプのシステムで処理できるようにします。
- Business Process Execution Language (BPEL)
- Web サービスを使用して、この言語を使用してビジネスルールをオーケストレーションできます。これは、ビジネスプロセス命令を簡単に実行するために SOA に含まれています。
- Java Universal Description、Discovery and Integration (jUDDI)
- これは SOA のデフォルトサービスレジストリーです。ここで説明する内容は、インストラクター上のサービスに関する情報をすべて保管する場所です。
- Smooks
- この変換エンジンは SOA と組み合わせて使用してメッセージを処理できます。また、メッセージを分割して正しい宛先に送信するためにも使用できます。
- JBoss ルール
- これは、SOA にパッケージ化されたルールエンジンです。受信するメッセージからデータを推測して、実行する必要があるアクションを判別できます。
1.9. JBoss Enterprise SOA Platform の JBossESB コンポーネントの機能
- 複数のトランスポートおよびプロトコル
- リスナーアクションモデル (これにより、サービスを相互に選択可能)
- コンテンツベースのルーティング (JBoss Rules エンジン、XPath、Regex、および Smooks 経由)
- サービスオーケストレーション機能を提供するために JBoss Business Process Manager (jBPM) との統合
- ビジネスルールの開発機能を提供するために、JBoss ルールとの統合
- BPEL エンジンとの統合。
- さまざまなトランスポートメカニズム (電子メールや JMS など) と連携するよう設定されます。
- 汎用オブジェクトリポジトリーとして使用します。
- プラグ可能なデータ変換メカニズムを実装できるようにします。
- 対話のロギングをサポートします。
org.jboss.internal.soa.esb
と org.jboss.soa.esb
の 2 つのツリーがあります。org.jboss.internal.soa.esb
パッケージの内容をそのまま使用します。これは、通知なしに変更される可能性があるためです。これとは対照的に、org.jboss.soa.esb
パッケージ内のすべての内容は、Red Hat の非推奨ポリシーでカバーされます。
1.10. タスク管理
1.11. 統合のユースケース
1.12. ビジネス環境での JBoss Enterprise SOA Platform の使用
第2章 jUDDI レジストリーの概要
2.1. 対象読者
2.2. 本書のねらい
2.3. データのバックアップ
2.4. juddi レジストリー
2.5. juddi および JBoss Enterprise SOA Platform
juddi および JBoss Enterprise SOA Platform
JBoss Enterprise SOA Platform 製品には、jUDDI レジストリーの事前設定されたインストールが含まれています。特定の API を使用して、カスタムクライアントを介してこのレジストリーにアクセスできます。ただし、ビルドするカスタムクライアントは SOA Platform のサポート契約では対応されません。jUDDI の例、ドキュメント、および API の完全なセットには、次の場所からアクセスできます。http://juddi.apache.org/
2.6. サポートされるその他のサービスレジストリー
- SOA ソフトウェア SMS
- HP Systinet
2.7. Service Registry
2.8. サービスプロバイダー
2.9. サービスブローカー
2.10. サービスリクエスター
2.11. Web サービス
2.12. Web サービスのエンドポイント
2.13. Web Services Description Language (WSDL)
- サービスの場所
- サービスがサポートする操作
- サービスがサポートするプロトコルバインディング (SOAP、HTTP など)
- アクセス手順
2.14. Universal Description、Discovery and Integration (UDDI) レジストリー
2.15. UDDI アプリケーションプログラミングインターフェイス
- UDDI_Security_PortType
- これは、セキュリティートークンを取得するための API を定義します。有効なセキュリティートークンでは、パブリッシャーはレジストリーに公開できます。セキュリティートークンは、セッション全体に使用できます。
- UDDI_Publication_PortType
- これにより、ビジネスおよびサービス情報を UDDI レジストリーに公開する API が定義されます。
- UDDI_Inquiry_PortType
- これは、UDDI レジストリーをクエリーする API を定義します。この API は通常、セキュリティートークンを必要としません。
- UDDI_CustodyTransfer_PortType
- この API は、ある UDDI ノードから別の UDDI ノードにビジネスのカストディを転送するために使用することができます。
- UDDI_Subscription_PortType
- これは、特定のサービスビジネスで更新を登録する API を定義します。
- UDDI_SubscriptionListener_PortType
- これは、UDDI ノードからサブスクリプション通知を受け取るためにクライアントが実装する必要のある API を定義します。
- UDDI_Replication_PortType
- これは、UDDI ノード間でレジストリーデータを複製する API を定義します。
- UDDI_ValueSetValidation_PortType
- これは、外部プロバイダーが検証を設定するのを許可するためにノードによって使用されます。keyedReferences または keyedReferenceGroups が有効かどうかを評価する Web サービス。
- UDDI_ValueSetCaching_PortType
- UDDI ノードは、このような Web サービスから取得したキャッシュされた値を使用して、パブリッシャー参照自体を検証することができます。
2.16. UDDI ページタイプ
- 緑色のページ
- 緑のページでは、クライアントを提供されているサービスにバインドできる情報を提供します。
- 黄色のページ
- 黄色のページは、所属する業界に基づいて企業を分類するために使用されます。
- ホワイトページ
- ホワイトページには、サービスを提供する会社の名前、住所、その他の連絡先情報などの一般情報が含まれます。
2.17. Service Registry および JBoss Enterprise SOA Platform
2.18. jUDDI および ESB
2.19. レジストリーの仕組み
- JBoss Enterprise Service Bus は、レジストリーインターフェイスを介したレジストリーとのすべての対話をフェデレーションします。
- その後、このインターフェイスの JAXR 実装を呼び出します。
- JAXR API は JAXR 実装を使用する必要があります。(デフォルトでは Apache Scout です。)
- Apache Scout は、次に レジストリー を呼び出します。
2.20. Apache スカウト
org.jboss.soa.esb.scout.proxy.transportClass
クラスにはそれぞれ SOAP、SAAJ、RMI、および Embedded Java (Local) 用の実装が 4 つあります。
2.21. Java API for XML Registries (JAXR)
2.22. レジストリーインターフェイス
2.23. 変数名:SOA_ROOT ディレクトリー
jboss-soa-p-5
ディレクトリーです。ただし、スタンドアロン編集では、jboss-soa-p-standalone-5
ディレクトリーになります。
SOA_ROOT
と呼ばれます。この名前がある場合は、必要に応じて jboss-soa-p-5
または jboss-soa-p-standalone-5
のいずれかを置き換えます。
2.24. 変数名: PROFILE
第3章 ルートシードデータの設定
3.1. サービスレジストリーパブリッシャー
- root
- ルートパブリッシャーは、ルートパーティションおよび UDDI サービスの所有者です(
inquiry
やpublication
など)。各レジストリーには ルートパブリッシャー が必要です。ノードごとにルートパブリッシャーは 1 つだけ存在できます。jUDDI レジストリーは、juddi-core-3.x.jar ファイルのjuddi-core-3.x.jar
ファイルのjuddi_install_data/
ディレクトリーにあるルートアカウントのデフォルトのシードデータを提供します。 - uddi
- UDDI は、他のすべてのシードデータを所有します (事前定義された
tModels
など)。
3.2. シードデータ
3.3. Service Registry のシードデータファイル
- <publisher>_Publisher.xml
- <publisher>_tModelKeyGen.xml
- <publisher>_BusinessEntity.xml
- <publisher>_tModels.xml
3.4. root_Publisher.xml
root_Publisher.xml
データシードファイルの内容は以下のようになります。
<publisher xmlns="urn:juddi-apache-org:api_v3" authorizedName="root"> <publisherName>root publisher</publisherName> <isAdmin>true</isAdmin> </publisher>
3.5. キー生成スキーマ
3.6. tModel
3.7. root_tModelKeyGen.xml
tModel Key Generator
は SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_tModelKeyGen.xml
ファイルで定義されます。
<tModel tModelKey="uddi:juddi.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>uddi-org:keyGenerator</name> <description>Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel>
ルートパブリッシャー
によって使用されるキーは uddi:juddi.apache.org:<text-of-choice>
の形式で指定する必要があります。
3.8. パブリッシャーのキー生成スキーマの作成
手順3.1 タスク
- 各パブリッシャーは、独自の KenGenerator tModel を定義する必要があります。tModel Key Generator は root_tModelKeyGen.xml ファイルで定義されます。
<tModel tModelKey="uddi:juddi.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>uddi-org:keyGenerator</name> <description>Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel>
- ルートパブリッシャーが使用するキーは、
uddi:juddi.apache.org:<text-of-choice>
形式である必要があります。別の形式を使用する場合は、不正なキーエラーが表示されます。警告KeyGenerators を共有しないでください。
3.9. Just One KeyGenerator tModel よりも多くのパブリッシャーを表示する
手順3.2 タスク
<publisher>_tModels.xml
ファイルを使用します。
3.10. パブリッシャーを使用したビジネスおよびサービスデータの設定
手順3.3 タスク
- テキストエディターで
<publisher>_BusinessEntity.xml
ファイルを開きます。vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml - ファイルを編集し、サービスを指定します。以下に例を示します。
<businessEntity xmlns="urn:uddi-org:api_v3" xmlns:xml="http://www.w3.org/XML/1998/namespace" businessKey="uddi:juddi.apache.org:businesses-asf"> <!-- Change the name field to represent the name of your registry --> <name xml:lang="en">An Apache jUDDI Node</name> <!-- Change the description field to provided a brief description of your registry --> <description xml:lang="en"> This is a UDDI v3 registry node as implemented by Apache jUDDI. </description> <discoveryURLs> <!-- This discovery URL should point to the home installation URL of jUDDI --> <discoveryURL useType="home"> http://${juddi.server.baseurl}/juddiv3 </discoveryURL> </discoveryURLs> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:nodes" keyValue="node" /> </categoryBag> <businessServices> <!-- As mentioned above, you may want to provide user-defined keys for these (and the services/bindingTemplates below. Services that you don't intend to support should be removed entirely --> <businessService serviceKey="uddi:juddi.apache.org:services-inquiry" businessKey="uddi:juddi.apache.org:businesses-asf"> <name xml:lang="en">UDDI Inquiry Service</name> <description xml:lang="en">Web Service supporting UDDI Inquiry API</description> <bindingTemplates> <bindingTemplate bindingKey="uddi:juddi.apache.org:servicebindings-inquiry-ws" serviceKey="uddi:juddi.apache.org:services-inquiry"> <description>UDDI Inquiry API V3</description> <!-- This should be changed to the WSDL URL of the inquiry API. An access point inside a bindingTemplate will be found for every service in this file. They all must point to their API's WSDL URL --> <accessPoint useType="wsdlDeployment"> http://${juddi.server.baseurl}/juddiv3/services/inquiry?wsdl </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_inquiry"> <instanceDetails> <instanceParms> <![CDATA[ <?xml version="1.0" encoding="utf-8" ?> <UDDIinstanceParmsContainer xmlns="urn:uddi-org:policy_v3_instanceParms"> <defaultSortOrder> uddi:uddi.org:sortorder:binarysort </defaultSortOrder> </UDDIinstanceParmsContainer> ]]> </instanceParms> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> <categoryBag> <keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" tModelKey="uddi:uddi.org:categorization:types"/> </categoryBag> </bindingTemplate> </bindingTemplates> </businessService> <businessService serviceKey="uddi:juddi.apache.org:services-publish" businessKey="uddi:juddi.apache.org:businesses-asf"> <name xml:lang="en">UDDI Publish Service</name> ........... </businessService> </businessServices> </businessEntity>
- ファイルを保存して終了します。警告juddi.seed.always を
true
に設定しない限り、シードプロセスは、データベースにパブリッシャー
がない場合にのみ開始します。(ルートデータファイル以外のすべてのファイルを再適用します。)これにより、再シードされたエンティティーに追加された情報は消去されるため、データが失われる可能性があります。これは、データがマージされないためです。
3.11. root_BusinessEntity.xml ファイルでのトークンの設定
手順3.4 タスク
- root_
BusinessEntity.xml
ファイル (${juddi.server.baseurl}
) でトークンの値を設定するには、SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルを変更します。テキストエディターで<publisher>_BusinessEntity.xml
ファイルを開きます。vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml - ここでは、キーおよびセキュリティートークンを設定できます。これらのセクションは、ニーズに合わせて変更します。
- ファイルを保存して終了します。注記値の置き換えは実行時に行われるため、必要に応じて異なるノードを独自の値に置き換えることができます。
3.12. シードデータのカスタム化
手順3.5 タスク
- 重要このシードデータはデータベースの設定に使用されるため、Service Registry を初めて起動する前にこれを実行する必要があります。プロセスを再実行する場合は、作成したデータベースを削除します。
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルでトークンを設定するのを忘れないでください。カスタムシードデータをjuddiv3.war/WEB-INF/classes/juddi_custom_install_data/
ディレクトリーに追加します。注記Sales Seed Data を使用するには、次のコマンドを実行してSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar//WEB-INF/classes/
にあるディレクトリーの名前を変更します: mv RENAME4Sales_juddi_custom_install_data juddi_custom_install_data注記ルートパブリッシャーがroot
と呼ばれていない場合は、SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルの juddi.root.publisher プロパティーを以下以外に設定する必要があります。juddi.root.publisher=root
プロパティーは以下のように設定されます。<entry key="juddi.root.publisher">root</entry>
第4章 API を介した単純な公開
4.1. UDDI データモデル
- ビジネスエンティティー
- ビジネスエンティティーは pyramid の上部にあります。ビジネスサービスが含まれます。
- Business services
- ビジネスサービスには、エンドポイントの参照が含まれます。
4.2. ビジネスエンティティー
4.3. ビジネスサービス
4.4. エンドポイント参照
4.5. UDDI および jUDDI API
セット
に分類されます。各 セット
は、機能の特定エリアを表します。
quiry は、
エンティティーの詳細についてレジストリーへのクエリーを処理します。公開
はエンティティーの登録を処理します。セキュリティー
は、認証を処理するオープンな仕様です。Custody および Ownership Transfer
はエンティティーの所有権の移譲を処理します。サブスクリプション
を使用すると、クライアントはサブスクリプション形式を使用してエンティティーに関する情報を取得できます。Subscription Listener
は、サブスクリプションの結果を受け入れるためのクライアント API です。- 値
セット(Validation および Caching)
は、キー化された参照値を検証します。(このセットは jUDDI では利用できません。) レプリケーションを
使用すると、レジストリーノード間でデータをフェデレーションできます。(このセットは jUDDI では利用できません。)
セット
は、 Inquiry
、 公開
、および セキュリティーです
。これらは、レジストリーとの対話に必要な標準的な機能を提供します。
セット
を JAX-WS 準拠の Web サービスとして実装します。(セットで定義された各メソッドは、対応する Web サービスのメソッドです。)
4.6. UDDI モデルへの juddi の追加
はじめに
jUDDI レジストリーの実装は、仕様に記載されている以外の追加の構造を持つデータモデルを提供します。これはパブリッシャーの概念です。
publish
呼び出しに割り当てられ、公開されたエンティティーに所有権を割り当てます。
4.7. チュートリアル: 初めてサービスレジストリーを使用する
手順4.1 タスク
SimplePublish
クラスをインスタンス化します。コンストラクターは次のとおりです。public SimplePublish() { try { String clazz = UDDIClientContainer.getUDDIClerkManager(null). getClientConfig().getUDDINode("default").getProxyTransport(); Class<?> transportClass = ClassUtil.forName(clazz, Transport.class); if (transportClass!=null) { Transport transport = (Transport) transportClass. getConstructor(String.class).newInstance("default"); security = transport.getUDDISecurityService(); juddiApi = transport.getJUDDIApiService(); publish = transport.getUDDIPublishService(); } } catch (Exception e) { e.printStackTrace(); } }
このコンストラクターは jUDDI クライアント API を使用して、デフォルトのノードからトランスポートを取得します。この例では、JAX-WS Web サービスを使用して UDDI 呼び出しを行うように設計されたデフォルトのクライアントトランスポートクラスを取得するだけです。- 例に必要な 3 つの API セットを取得します。
- 承認トークンを取得できるように
Security
API セット - パブリッシャーを保存できるようにプロプライエタリーの
jUDDI
API セット - エンティティーを jUDDI に登録できるように
公開
API が設定されている。
以下は、publish
メソッドの最初の数行です。// Setting up the values to get an authentication token for the 'root' user // ('root' user has admin privileges and can save other publishers). GetAuthToken getAuthTokenRoot = new GetAuthToken(); getAuthTokenRoot.setUserID("root"); getAuthTokenRoot.setCred(""); // Making API call that retrieves the authentication token for the 'root' user. AuthToken rootAuthToken = security.getAuthToken(getAuthTokenRoot); System.out.println ("root AUTHTOKEN = " + rootAuthToken.getAuthInfo());
このコードは、root ユーザーの承認トークンのみを取得します。 - パブリッシャーを追加します。
// Creating a new publisher that we will use to publish our entities to. Publisher p = new Publisher(); p.setAuthorizedName("my-publisher"); p.setPublisherName("My Publisher"); // Adding the publisher to the "save" structure, using the 'root' user authentication // info and saving away. SavePublisher sp = new SavePublisher(); sp.getPublisher().add(p); sp.setAuthInfo(rootAuthToken.getAuthInfo()); juddiApi.savePublisher(sp);
上記のコードは、jUDDI API を使用して、作成者名 my-publisher を持つパブリッシャーを保存します。root ユーザーの承認トークンは使用されていることに注意してください。 - この新しいパブリッシャーの承認トークンを取得します。
// Our publisher is now saved, so now we want to retrieve its authentication token GetAuthToken getAuthTokenMyPub = new GetAuthToken(); getAuthTokenMyPub.setUserID("my-publisher"); getAuthTokenMyPub.setCred(""); AuthToken myPubAuthToken = security.getAuthToken(getAuthTokenMyPub); System.out.println ("myPub AUTHTOKEN = " + myPubAuthToken.getAuthInfo());
認可呼び出しのいずれかに認証情報が設定されていないことに注意してください。これは、デフォルトのオーセンティケーターを使用することで何も指定する必要がないためです。 - パブリッシュ:
// Creating the parent business entity that will contain our service. BusinessEntity myBusEntity = new BusinessEntity(); Name myBusName = new Name(); myBusName.setValue("My Business"); myBusEntity.getName().add(myBusName); // Adding the business entity to the "save" structure, using our publisher's // authentication info and saving away. SaveBusiness sb = new SaveBusiness(); sb.getBusinessEntity().add(myBusEntity); sb.setAuthInfo(myPubAuthToken.getAuthInfo()); BusinessDetail bd = publish.saveBusiness(sb); String myBusKey = bd.getBusinessEntity().get(0).getBusinessKey(); System.out.println("myBusiness key: " + myBusKey); // Creating a service to save. Only adding the minimum data: the parent // business key retrieved from saving the business above and a single name. BusinessService myService = new BusinessService(); myService.setBusinessKey(myBusKey); Name myServName = new Name(); myServName.setValue("My Service"); myService.getName().add(myServName); // Add binding templates, etc... // Adding the service to the "save" structure, using our publisher's // authentication info and saving away. SaveService ss = new SaveService(); ss.getBusinessService().add(myService); ss.setAuthInfo(myPubAuthToken.getAuthInfo()); ServiceDetail sd = publish.saveService(ss); String myServKey = sd.getBusinessService().get(0).getServiceKey(); System.out.println("myService key: " + myServKey);
注記エンティティーキーの使用に関する重要な事項があります。バージョン 3 仕様では、パブリッシャーが独自のキーを作成できますが、実装者にデフォルトのメソッドがあることを指示します。Red Hat は、save
呼び出しで各エンティティーの key フィールドを空白のままにして、デフォルトの実装アプローチを選択しました。jUDDI のデフォルトのキージェネレーターは、ノードのパーティションを取り、GUID を追加します。デフォルトのインストールでは、以下のようになります。uddi:juddi.apache.org:<GUID>
(当然ながら、これをすべてカスタマイズすることができます。)2 つ目の点は、 BusinessService を保存すると、親ビジネスキー (ビジネスを保存する以前の呼び出しから取得) が明示的に設定されていることです。これは、サービスが独立した呼び出しに保存されている場合に必要な手順です。これは、jUDDI が親エンティティーの場所を認識しないため、エラーが発生します。
結果
この例では、 BusinessEntity を作成して保存し、 BusinessService を作成および保存しました。最小限のデータを各エンティティーに追加している (実際は、 BindingTemplates をサービスに追加していない)。
第5章 サブスクリプション
5.1. サブスクリプション API
サブスクリプション
API を使用すると、異なるサービスレジストリーでサービスを相互登録し、親レジストリーのレジストリー情報として通知を送信してそれらを最新の状態に保つことができます。これは、大規模または複雑な組織があり、部門ごとに異なるサービスレジストリーを実行し、それらの間で共有されるサービスがある場合に役立ちます。
5.2. サブスクリプションタイプ
- 非同期
- これにより、サブスクリプションを保存し、設定されたスケジュールで更新を受け取ることができます。通知を送信するノードにリスナーサービスをインストールする必要があります。
- 同期
- これにより、サブスクリプションを保存し、
get_Subscription
を呼び出して同期応答を取得できます。
5.3. チュートリアル: サブスクリプション
前提条件
- この例では、
営業
およびマーケティング
用にノードを設定します。これを実行するには、最初に Service Registry を 2 つの異なるサービスにデプロイする必要があります。
手順5.1 タスク
ノード 1 の設定: 営業
以下のコマンドを実行してjuddi_custom_install_data
を作成します。cd juddiv3/WEB-INF/classesmv RENAME4SALES_juddi_custom_install_data juddi_custom_install_data- テキストエディターで
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルを開き、以下のプロパティー値を設定します (sales はサーバーの DNS 名に置き換えます)。juddi.server.name=sales juddi.server.port=8080
- ファイルを保存して終了します。
- サーバーを起動します。SOA_ROOT/jboss-as/bin/./run.sh
- Web ブラウザーを開き、このアドレス に移動します: http://sales:8080/juddiv3ノードについての情報を提供するメッセージが表示されるはずです。
ノード 2 の設定: マーケティング
以下のコマンドを実行してjuddi_custom_install_data
を作成します。cd juddiv3/WEB-INF/classesmv RENAME4MARKETING_juddi_custom_install_data juddi_custom_install_data- テキストエディターで
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルを開き、以下のプロパティー値を設定します (これはサーバーの DNS 名です)。juddi.server.name=marketing juddi.server.port=8080
- ファイルを保存して終了します。
- サーバーを起動します。SOA_ROOT/jboss-as/bin/./run.sh
- Web ブラウザーを開き、このアドレス に移動します: http://sales:8080/juddiv3ここでも、ノードについての情報を提供するメッセージが表示されます。注記営業部門とマーケティング部門の両方が同じ会社にあるため、ルートパーティションは同じままでしたが、 Node Id と Name は各ノードが異なる部門に属することを反映するように変更されている点に注意してください。
- 次に、営業サーバーの
uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml
ファイルをuddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml.sales
に置き換えます。 - テキストエディターで
uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml
ファイルを開き、以下のプロパティーを追加します。<name>default</name> <properties> <property name="serverName" value="sales"/> <property name="serverPort" value="8080"/> <property name="rmiPort" value="1099"/> </properties>
- ファイルを保存して終了します。
- Web ブラウザーを起動し、このアドレスに移動します: http://sales:8080/pluto
- ユーザー名とパスワードの両方で
sales
にログインし、画面に表示される内容を確認します。 - マーケティングポータルにログインする前に、マーケティングの
uddi-portlet.war/WEB-INF/classes/META-INF/uddi.xml
ファイルをudd-portlet.war/WEB-INF/classes/META-INF/uddi.xml.marketing
に置き換えます。 - テキストエディターで
uddi-portlet.war/WEB-INF/classes/META_INF/uddi.xml
ファイルを開き、以下のプロパティーを追加します。<name>default</name> <properties> <property name="serverName" value="marketing"/> <property name="serverPort" value="8080"/> <property name="rmiPort" value="1099"/> </properties>
- ファイルを保存して終了します。
- Web ブラウザーを起動し、このアドレス に移動します: http://marketing:8080/pluto
- ユーザー名とパスワードの両方で
sales
にログインし、画面に表示される内容を確認します。注記subscriptionlistener は、Root Marketing ノードではなく、Marketing Node business によって所有されています。マーケティングノードビジネスはマーケティングパブリッシャーによって管理されます。
5.4. チュートリアル: HelloSales サービスのデプロイ
手順5.2 タスク
- テキストエディターで
juddiv3-samples.war/WEB-INF/classes/META-INF/uddi.xml
ファイルを開き、以下のプロパティー値を sales に追加します。<?xml version="1.0" encoding="ISO-8859-1" ?> <uddi> <reloadDelay>5000</reloadDelay> <manager name="example-manager"> <nodes> <node> <name>default</name> <description>Sales jUDDI node</description> <properties> <property name="serverName" value="sales"/> <property name="serverPort" value="8080"/> <property name="keyDomain" value="sales.apache.org"/> <property name="department" value="sales" /> </properties> <proxyTransport> org.apache.juddi.v3.client.transport.InVMTransport </proxyTransport> <custodyTransferUrl> org.apache.juddi.api.impl.UDDICustodyTransferImpl </custodyTransferUrl> <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl> <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl> <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl> <subscriptionUrl> org.apache.juddi.api.impl.UDDISubscriptionImpl </subscriptionUrl> <subscriptionListenerUrl> org.apache.juddi.api.impl.UDDISubscriptionListenerImpl </subscriptionListenerUrl> <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl> </node> </nodes> </manager> </uddi>
- ファイルを保存して終了します。
- 次に、
juddiv3-samples.war
を営業レジストリーにデプロイします。ant deployant runtest注記HelloSales サービスはjuddiv3-samples.war
アーカイブファイルで提供され、アノテーションが付けられているため、自動的に登録されます。 - Marketing UDDI ノード内から営業 UDDI ノードの HelloWord サービスにサブスクライブします。
5.5. ユーザーが独自のサブスクリプションを作成できるようにする
前提条件
- ユーザーがサブスクリプションを作成して保存するには、営業ノードとマーケティングノードの両方に有効なパブリッシュ済みのログインが必要です。
- マーケティングパブリッシャーがマーケティングノードでレジストリーオブジェクトを作成する場合、マーケティングパブリッシャーは
sales keygenerator tModel
を所有する必要があります。マーケティングレジストリーのマーケティングパブリッシャーが以下のtModels
を所有することを理解することが重要です。<save_tModel xmlns="urn:uddi-org:api_v3"> <tModel tModelKey="uddi:marketing.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>marketing-apache-org:keyGenerator</name> <description>Marketing domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> <tModel tModelKey="uddi:marketing.apache.org:subscription:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>marketing-apache-org:subscription:keyGenerator</name> <description>Marketing Subscriptions domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> <tModel tModelKey="uddi:sales.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>sales-apache-org:keyGenerator</name> <description>Sales Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> </save_tModel>
手順5.3 タスク
- マーケティングパブリッシャーを使用して営業レジストリーの更新をサブスクライブする場合は、このパブリッシャーに 2 つのクラークを提供する必要があります。これを行うには、テキストエディターで
uddi-portlet.war/uddi.xml
ファイルを開き、以下の行を追加します。<clerks registerOnStartup="false"> <clerk name="MarketingCratchit" node="default" publisher="marketing" password="marketing"/> <clerk name="SalesCratchit" node="sales-ws" publisher="marketing" password="marketing"/> <!-- optional <xregister> <servicebinding entityKey="uddi:marketing.apache.org:servicebindings-subscriptionlistener-ws" fromClerk="MarketingCratchit" toClerk="SalesCratchit"/> </xregister> --> </clerks>
上記のコードでは、このパブリッシャー ( MarketingCratchit と SalesCratchit) の 2 つのクラークを作成しました。これにより、パブリッシャーは 2 つのシステムごとに所有しているサブスクリプションを確認できます。 - ファイルを保存して終了します。
- マーケティングポータルでマーケティングパブリッシャーとしてログインし、UDDISubscription Portlet を選択します。
- 両方のノードが緑色に変わったら、 new subscription アイコン (ツールバーに格納) をクリックします。 これは同期サブスクリプションであるため、Binding Key および Notification Interval のみが残されます。
- Save アイコンをクリックして、サブスクリプションを保存します。
- サブスクリプションキーがマーケティングパブリッシャーの
keyGenerator
の規則を使用していることを確認してください。sales-ws
UDDI ノードにオレンジ色のサブスクリプションアイコンが表示されるはずです。 - 同期サブスクリプションを呼び出すには、 Green Arrows アイコンをクリックします。これにより、カバレッジ期間を設定する機会が与えられます。
- Green Arrows アイコンを再度クリックして、同期サブスクリプションリクエストを呼び出します。finder リクエストの例では、sales ノードが
HelloWorld
サービスへの更新を検索します。その後、raw の XML 応答がUDDISubscriptionNotification
ポートレットに送信されます。 - レスポンスはマーケティングノードによって処理されます。次に、このノードは
HelloWorld
サブスクリプション情報とsales business
をインポートします。正常に同期すると、3 つの企業がマーケティングノードのブラウザーポートレットに表示されます。
第6章 M-Bean のサポート
6.1. M-Bean
6.2. jUDDI M-Beans
- org.apache.juddi.api.impl.UDDIServiceCounter
- org.apache.juddi.api.impl.UDDICustodyTransferCounter
- org.apache.juddi.api.impl.UDDIInquiryCounter
- org.apache.juddi.api.impl.UDDIPublicationCounter
- org.apache.juddi.api.impl.UDDISecurityCounter
- org.apache.juddi.api.impl.UDDISubscriptionCounter
- 正常なクエリー
- 失敗したクエリー
- クエリーの合計
- 処理時間
- API ごとの合計/成功/失敗の集約数
第7章 jUDDI クライアントの使用
7.1. jUDDI クライアント
SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/lib/juddi-client-VERSION.jar
にあります。
7.2. jUDDI クライアント依存関係
uddi-ws-3.0.0.jar
commons-configuration-1.5.jar
commons-collection-3.2.1.jar
log4j-1.2.13.jar
- JDK6 のライブラリー。
- JAXWS クライアントライブラリー (CXF などの JAXWS トランスポートを使用している場合)
- RMI および JNDI クライアントライブラリー (RMI トランスポートを使用している場合)。
7.3. jUDDI クライアントおよび JBoss Enterprise SOA Platform
7.4. トランスポート設定
7.5. uddi.xml
META-INF/uddi.xml
ファイルには、jUDDI クライアントの設定が含まれます。このファイルは、UDDI クライアントコードと対話するデプロイメントアーカイブに追加できます。
7.6. カスタム jUDDI クライアント設定のデプロイ
手順7.1 タスク
- テキストエディターで META-INF/uddi.xml を開きます。
- 設定を構成します。
- 保存して終了します。
- デプロイ時に uddi.xml ファイルをアーカイブに追加します。
- このコードを呼び出します。
UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start();
- または、アプリケーションが WAR アーカイブとしてデプロイする場合は、クライアント設定を
yourwar/META-INF/myuddi.xml
に追加し、web.xml ファイルで以下のコンテキストパラメーターuddi.client.manager.name
およびuddi.client.xml
を指定します。この例では、両方のコンテキストパラメーターが設定され、デプロイ時に UDDIClerkServlet が設定を読み取ります。<!-- required --> <context-param> <param-name>uddi.client.manager.name</param-name> <param-value>example-manager</param-value> </context-param> <!-- optional override --> <context-param> <param-name>uddi.client.xml</param-name> <param-value>META-INF/myuddi.xml</param-value> </context-param> <servlet> <servlet-name>UDDIClerkServlet</servlet-name> <display-name>Clerk Servlet</display-name> <servlet-class>org.apache.juddi.v3.client.config.UDDIClerkServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>
7.7. jUDDI クライアント設定ファイルの例
<?xml version="1.0" encoding="ISO-8859-1" ?> <uddi> <reloadDelay>5000</reloadDelay> <manager name="example-manager"> <nodes> <node isHomeJUDDI="true"> <name>default</name> <description>jUDDI node</description> <properties> <property name="serverName" value="www.myuddiserver.com"/> <property name="serverPort" value="8080"/> <property name="keyDomain" value="mydepartment.mydomain.org"/> <property name="department" value="mydepartment" /> </properties> <!-- InVM --> <proxyTransport>org.apache.juddi.v3.client.transport.InVMTransport</proxyTransport> <custodyTransferUrl>org.apache.juddi.api.impl.UDDICustodyTransferImpl</custodyTransferUrl> <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl> <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl> <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl> <subscriptionUrl>org.apache.juddi.api.impl.UDDISubscriptionImpl</subscriptionUrl> <subscriptionListenerUrl>org.apache.juddi.api.impl.UDDISubscriptionListenerImpl</subscriptionListenerUrl> <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl> <!-- JAX-WS Transport <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport> <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer</custodyTransferUrl> <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry</inquiryUrl> <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish</publishUrl> <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security</securityUrl> <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription</subscriptionUrl> <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener</subscriptionListenerUrl> <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl> --> <!-- RMI Transport Settings <proxyTransport>org.apache.juddi.v3.client.transport.RMITransport</proxyTransport> <custodyTransferUrl>/juddiv3/UDDICustodyTransferService</custodyTransferUrl> <inquiryUrl>/juddiv3/UDDIInquiryService</inquiryUrl> <publishUrl>/juddiv3/UDDIPublicationService</publishUrl> <securityUrl>/juddiv3/UDDISecurityService</securityUrl> <subscriptionUrl>/juddiv3/UDDISubscriptionService</subscriptionUrl> <subscriptionListenerUrl>/juddiv3/UDDISubscriptionListenerService</subscriptionListenerUrl> <juddiApiUrl>/juddiv3/JUDDIApiService</juddiApiUrl> <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial> <javaNamingFactoryUrlPkgs>org.jboss.naming</javaNamingFactoryUrlPkgs> <javaNamingProviderUrl>jnp://${serverName}:1099</javaNamingProviderUrl> --> </node> </nodes> <clerks registerOnStartup="true"> <clerk name="BobCratchit" node="default" publisher="bob" password="bob"> <class>org.apache.juddi.samples.HelloWorldImpl</class> </clerk> </clerks> </manager> </uddi>
isHomeJUDDI="true"
を設定しますが、リモートレジストリーの場合は isHomeJUDDI="false"
を設定します。
表7.1 要素
要素名 | Description | 必須 ? |
---|---|---|
name | ノードの名前 | はい |
description | ノードの説明 | いいえ |
properties | クラークに渡されるプロパティーのコンテナー | いいえ |
proxyTransport | UDDI サーバーに接続するためにクライアントが使用するトランスポートプロトコル | はい |
custodyTransferUrl | カストディ転送の接続設定 | いいえ |
inquiryUrl | 問い合わせの接続ロケーションの設定 | はい |
publishUrl | 公開用の接続ロケーションの設定 | はい |
securityUrl | セキュリティートークンを取得するための接続ロケーションの設定 | はい |
subscriptionUrl | サブスクリプションリクエストを登録するための接続ロケーションの設定 | いいえ |
subscriptionListenerUrl | サブスクリプション通知を受信する接続ロケーションの設定 | いいえ |
juddiApiUrl | パブリッシャー管理など、jUDDI 固有の API の接続ロケーション設定 | いいえ |
表7.2 クラーク
属性名 | Description | 必須 ? |
---|---|---|
name | クラークの名前 | はい |
node | 同じマネージャーで指定されたノードの 1 つへの名前参照 | はい |
publisher | 既存のパブリッシャーの名前 | はい |
password | パブリッシャーのパスワード認証情報 | はい |
7.8. Java API for XML Web Services (JAX-WS)
7.9. JAX-WS トランスポートの設定
前提条件
uddi.xml
ファイルの設定に基づいて、クライアントは JAX-WS を使用して (リモート) レジストリーサーバーと通信します。これは、クライアントが JAX-WS 準拠の Web サービススタック (CXF、Axis2、JBossWS など) にアクセスできる必要があることを意味します。
手順7.2 タスク
- JAX-WS URL は、UDDI クライアントが WSDL ドキュメントを見つけることができるアドレスを参照していることを確認します。
<!-- JAX-WS Transport --> <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport> <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer</custodyTransferUrl> <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry</inquiryUrl> <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish</publishUrl> <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security</securityUrl> <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription</subscriptionUrl> <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener</subscriptionListenerUrl> <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl>
重要長所: これは UDDI 通信を実行する標準的な方法であり、すべての UDDIv3 サーバー実装で動作するはずです。短所: サーバーが同じアプリケーションサーバーにデプロイメントされている場合、デプロイメント/デプロイメント解除の自動登録を使用すると、デプロイメント解除中に WS スタックが使用できなくなる可能性があるため、問題が発生する可能性があります。回避策は、別のサーバーで UDDI サーバーをホストすることです。
7.10. リモート呼び出しクラス
7.11. jUDDI とリモートメソッド呼び出し
7.12. jUDDI のリモートメソッド呼び出しの有効化
手順7.3 タスク
- jUDDI 設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml。
- 設定を編集し、プロパティー <entry key="juddi.jndi.registration">true</entry> を設定します。true に設定すると、RMI メソッドが jndi に登録され、検索して呼び出すことができます。デフォルトは true です。
- ファイルを保存して終了します。
- テキストエディターで UDDI 設定ファイルを開きます: vi META-INF/uddi.xml。
- ファイルの JAX-WS セクションをコメントアウトし、代わりに RMI セクションのコメントを外します。
- オプションの手順として、 java.naming.* プロパティーを設定することもできます。この例では、JBoss Application Server にデプロイされた jUDDI v3 に接続するための設定を指定しました。その代わりに、
jndi.properties
ファイルやシステムパラメータとして java.naming.* プロパティを設定することができます。<!-- RMI Transport Settings --> <proxyTransport>org.apache.juddi.v3.client.transport.RMITransport</proxyTransport> <custodyTransferUrl>/juddiv3/UDDICustodyTransferService</custodyTransferUrl> <inquiryUrl>/juddiv3/UDDIInquiryService</inquiryUrl> <publishUrl>/juddiv3/UDDIPublicationService</publishUrl> <securityUrl>/juddiv3/UDDISecurityService</securityUrl> <subscriptionUrl>/juddiv3/UDDISubscriptionService</subscriptionUrl> <subscriptionListenerUrl>/juddiv3/UDDISubscriptionListenerService</subscriptionListenerUrl> <juddiApiUrl>/juddiv3/JUDDIApiService</juddiApiUrl> <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial> <javaNamingFactoryUrlPkgs>org.jboss.naming</javaNamingFactoryUrlPkgs> <javaNamingProviderUrl>jnp://${serverName}:1099</javaNamingProviderUrl>
重要長所: Web サービススタックを必要としないため、軽量で高速です。短所: jUDDI v3 サーバー実装でのみ機能します。 - ファイルを保存して終了します。
結果
これをデプロイすると、RMI ベースの UDDI サービスがグローバル JNDI 名前空間にバインドされます。
- juddiv3 (class:
org.jnp.interfaces.NamingContext
) - UDDIPublicationService (class:
org.apache.juddi.rmi.UDDIPublicationService
) - UDDICustodyTransferService (class:
org.apache.juddi.rmi.UDDICustodyTransferService
) - UDDISubscriptionListenerService (class:
org.apache.juddi.rmi.UDDISubscriptionListenerService
) - UDDISecurityService (class:
org.apache.juddi.rmi.UDDISecurityService
) - UDDISubscriptionService (class:
org.apache.juddi.rmi.UDDISubscriptionService
) - UDDIInquiryService (class:
org.apache.juddi.rmi.UDDIInquiryService
)
7.13. InVM トランスポート
7.14. InVM と jUDDI
juddi.war
アーカイブにデプロイする場合、サーバーは org.apache.juddi.RegistryServlet
クラスによって開始されますが、コンテナーの外部で実行している場合は、org.apache.juddi.Registry
サービスを自分で開始および停止する必要があります。
7.15. jUDDI の InVM トランスポートの設定
手順7.4 タスク
- テキストエディターで UDDI 設定ファイルを開きます: vi META-INF/uddi.xml。
- ファイルの JAX-WS および RMI トランスポートセクションをコメントアウトし、代わりに InVM トランスポートセクションのコメントを外します。
<!-- InVM --> <proxyTransport>org.apache.juddi.v3.client.transport.InVMTransport</proxyTransport> <custodyTransferUrl>org.apache.juddi.api.impl.UDDICustodyTransferImpl</custodyTransferUrl> <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl> <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl> <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl> <subscriptionUrl>org.apache.juddi.api.impl.UDDISubscriptionImpl</subscriptionUrl> <subscriptionListenerUrl>org.apache.juddi.api.impl.UDDISubscriptionListenerImpl</subscriptionListenerUrl> <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl>
重要長所: 軽量であり、通信に最高のパフォーマンスを提供します。デプロイメントおよびデプロイメント解除時にサービスの自動登録を使用する場合、デプロイメント順序の問題はありません。短所: jUDDI v3 サーバー実装でのみ機能します。通常、1 つの共通データベースを共有するアプリケーションサーバーごとに jUDDI サーバーを使用します。 - ファイルを保存して終了します。
7.16. InVM トランスポートを使用したサービスレジストリーの開始
- 他の呼び出しを行う前に、次のメソッドを呼び出します: Registry.start()
7.17. InVM トランスポートを使用したサービスレジストリーの停止
手順7.5 タスク
- 他の呼び出しを行う前に、次のメソッドを呼び出します: Registry.stop()
結果
レジストリーは、保持しているリソースをすべて解放します。
7.18. UDDI アノテーション
7.19. UDDIService アノテーションの使用
手順7.6 タスク
- UDDIService アノテーションを使用して、レジストリー内の既存のビジネスでサービスを登録します。アノテーションは、Java クラスのクラスレベルに追加する必要があります。
7.20. UDDIService 属性
表7.3
属性 | Description | 必須 ? |
---|---|---|
serviceName | これはサービスの名前です。デフォルトでは、クラークは WebService アノテーションで指定された 1 つの名前を使用します。 | いいえ |
description | これは、人間が判読できるサービスの説明です。 | はい |
serviceKey | これは、サービスの UDDI v3 キーです。 | はい |
businessKey | これは、サービスを所有する必要があるビジネスの UDDI v3 キーです。(ビジネスは登録時にレジストリーに存在している必要があります。) | はい |
lang | これは、名前と説明に使用される言語ロケールです。(省略した場合のデフォルトは en です。) | いいえ |
categoryBag | これは、CategoryBag の定義です。 | いいえ |
7.21. UDDIServiceBinding アノテーションの使用
手順7.7 タスク
- UDDIServiceBinding アノテーションを使用して、サービスレジストリーにエンドポイント参照を登録します。アノテーションは、Java クラスのクラスレベルに追加する必要があります。注記このアノテーションは単独で使用できません。 UDDIService アノテーション内で利用する必要があります。
7.22. UDDIServiceBinding 属性
表7.4 UDDIServiceBinding 属性
属性 | Description | 必須 ? |
---|---|---|
bindingKey | これは ServiceBinding の UDDI v3 キーです。 | はい |
description | これは、人間が判読できるサービスの説明です。 | はい |
accessPointType | これは UDDI v3 の AccessPointType です。(省略した場合、デフォルトでは wsdlDeployment です。) | いいえ |
accessPoint | これは、エンドポイントの参照です。 | はい |
lang | これは、名前と説明に使用される言語ロケールです(省略した場合はデフォルトで en になります)。 | いいえ |
tModelKeys | これは、 tModelKeys キー参照のコンマ区切りリストです。 | いいえ |
categoryBag | これは、CategoryBag の定義です。 | いいえ |
7.23. UDDI アノテーションの使用例
はじめに
サービスを定義する任意のクラスでアノテーションを使用できます。ここでは、それらが Web サービス (JAX-WS Web サービスアノテーションを持つ POJO) に追加されます。
package org.apache.juddi.samples; import javax.jws.WebService; import org.apache.juddi.v3.annotations.UDDIService; import org.apache.juddi.v3.annotations.UDDIServiceBinding; @UDDIService( businessKey="uddi:myBusinessKey", serviceKey="uddi:myServiceKey", description = "Hello World test service") @UDDIServiceBinding( bindingKey="uddi:myServiceBindingKey", description="WSDL endpoint for the helloWorld Service. This service is used for " + "testing the jUDDI annotation functionality", accessPointType="wsdlDeployment", accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl") @WebService( endpointInterface = "org.apache.juddi.samples.HelloWorld", serviceName = "HelloWorld") public class HelloWorldImpl implements HelloWorld { public String sayHi(String text) { System.out.println("sayHi called"); return "Hello " + text; } }
juddi-client
コードはこのクラスをスキャンして UDDI アノテーションを探し、登録プロセスを処理します。
org.apache.juddi.samples.HelloWorldImpl
サービスクラスを参照する必要があります。
<clerk name="BobCratchit" node="default" publisher="sales" password="sales"> <class>org.apache.juddi.samples.HelloWorldImpl</class> </clerk>
default
という名前のノードの接続設定を使用し、sales
パブリッシャーを使用するように指定します (パスワードは sales
です)。
7.24. CategoryBag 属性
7.25. CategoryBag アノテーションの使用例
<categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" /> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:wsdl2" keyValue="wsdlDeployment2" /> </categoryBag>
categoryBag="keyedReference=keyName=uddi-org:types:wsdl;keyValue=wsdlDeployment;" + "tModelKey=uddi:uddi.org:categorization:types," + "keyedReference=keyName=uddi-org:types:wsdl2;keyValue=wsdlDeployment2;" + "tModelKey=uddi:uddi.org:categorization:types2",
7.26. アノテーションを使用した Web サービスの開発
手順7.8 タスク
- サービスを定義する任意のクラスにアノテーションを追加します。以下は、JAX-WS Webservice アノテーションを使用して Web サービス POJO に追加する例です。
package org.apache.juddi.samples; import javax.jws.WebService; import org.apache.juddi.v3.annotations.UDDIService; import org.apache.juddi.v3.annotations.UDDIServiceBinding; @UDDIService(businessKey="uddi:myBusinessKey", serviceKey="uddi:myServiceKey", description = "Hello World test service") @UDDIServiceBinding(bindingKey="uddi:myServiceBindingKey", description="WSDL endpoint for the helloWorld Service. This service is used for " + "testing the jUDDI annotation functionality", accessPointType="wsdlDeployment", accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl") @WebService(endpointInterface = "org.apache.juddi.samples.HelloWorld", serviceName = "HelloWorld") public class HelloWorldImpl implements HelloWorld { public String sayHi(String text) { System.out.println("sayHi called"); return "Hello " + text; } }
この WebService のデプロイ時に、juddi-client コードはこのクラスをスキャンして UDDI アノテーションを探し、登録プロセスを処理します。 - テキストエディターで uddi.xml ファイルを開きます。vi uddi.xml
- クラークセクションまでスクロールして、
org.apache.juddi.samples.HelloWorldImpl
サービスクラスへの参照を追加します。<clerks registerOnStartup="true"> <clerk name="BobCratchit" node="default" publisher="bob" password="bob"> <class>org.apache.juddi.samples.HelloWorldImpl</class> </clerk> </clerks>
この例では、Bob は default という名前のノードの接続設定を使用しています。さらに、パスワードも bob である bob という名前のパブリッシャーを使用します。 - ファイルを保存して終了します。
7.27. キーテンプレート
uddi.xml
ファイルのプロパティーセクションで定義されます。
uddi.xml
ファイルで手動で設定することもできます。このテンプレートでプロパティーに設定した値は、キーの登録時に使用されます。
7.28. キーテンプレートのプロパティー
表7.5 キーテンプレートのプロパティー
プロパティー | Description | 必須 ? | デフォルト値 |
---|---|---|---|
lang | 登録で使用される言語設定 | いいえ | en |
businessName | 登録が使用するビジネス名 | はい | - |
keyDomain | キードメインのキー部分 (キーフォーマットで使用) | はい | - |
businessKeyFormat | ビジネスキーの作成に使用するキー形式 | いいえ | uddi:${keyDomain}:business_${businessName} |
serviceKeyFormat | BusinessService キーの作成に使用するキー形式 | いいえ | uddi:${keyDomain}:service_${serviceName} |
bindingKeyFormat | TemplateBinding キーの作成に使用されるキー形式 | いいえ | uddi:${keyDomain}:binding_${nodeName}_${serviceName}_${portName} |
serviceDescription | デフォルトの BusinessService の説明 | いいえ | <wsdl:service> 要素内に <wsdl:document> 要素が定義されていない場合のデフォルトのサービスの説明 |
bindingDescription | デフォルトの BindingTemplate の説明 | いいえ | <wsdl:binding> 要素内に <wsdl:document> 要素が定義されていない場合のデフォルトのバインディングの説明 |
7.29. アプリケーションでの jUDDI クライアントコードの使用
手順7.9 タスク
- jUDDI クライアント設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml。このファイルを独自の
uddi.xml
ファイルのテンプレートとして使用します。 - カスタム uddi.xml がインスタンス化されたときに、クラークマネージャーがそのカスタム
uddi.xml
を指していることを確認してください。UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start(); UDDIClerk clerk = clerkManager.getClientConfig().getUDDIClerks().get(clerkName);
注記UDDIClerk を使用すると、UDDI サーバーに対して認証済みのリクエストを行うことができます。
7.30. WSDL および UDDI レジストリー
7.31. WSDL におけるサービスとバインディングの説明の仕様
uddi.xml
ファイルにあります。ただし、各サービスやバインディングに固有の説明がある方がはるかに理にかなっているので、登録コードはこれらの説明を WSDL の <wsdl:document> タグから取得しようとします。このタグは <wsdl:service> と <wsdl:binding> 要素の内部に子要素としてネストさせることが可能です。
7.32. jUDDI での WSDL プロセスの登録
前提条件
- org.apache.juddi.v3.client.mapping
手順7.10 タスク
org.apache.juddi.v3.client.mapping
パッケージのコードを使用します。- 以下の呼び出しを行い、Web サービスのエンドポイントを非同期に登録します。
//Add the properties from the uddi.xml properties.putAll(clerk.getUDDINode().getProperties()); RegistrationInfo registrationInfo = new RegistrationInfo(); registrationInfo.setServiceQName(serviceQName); registrationInfo.setVersion(version); registrationInfo.setPortName(portName); registrationInfo.setServiceUrl(serviceUrl); registrationInfo.setWsdlUrl(wsdlURL); registrationInfo.setWsdlDefinition(wsdlDefinition); registrationInfo.setRegistrationType(RegistrationType.WSDL); registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo); Thread thread = new Thread(registration); thread.start();
注記これは、WSDLDefinition に加えて、WSDL ファイルに URL を渡すことができることを前提としています。ほとんどの場合、デプロイメントに登録する WSDL ファイルをパッケージ化する必要があります。WSDLDefinition を取得するには、以下のコードを使用します。ReadWSDL readWSDL = new ReadWSDL(); Definition definition = readWSDL.readWSDL("wsdl/HelloWorld.wsdl");
クラスパスにある WSDL にパス情報を渡す必要があります。
7.33. サービスレジストリーからの WSDL バインディングの削除
手順7.11 タスク
- サービスレジストリーから WSDL バインディングを削除するには、以下のコードを使用します。
WSDL2UDDI wsdl2UDDI = new WSDL2UDDI(clerk, urlLocalizer, properties); String serviceKey = wsdl2UDDI.unRegister(serviceName, portName, serviceURL);
注記これが BusinessService の最後の BindingTemplate である場合、WSDLPortType および WSDLBinding TModel とともに BusinessService 自体も削除されます。ライフサイクルは、エンドポイントのデプロイ時に registration に設定され、エンドポイントの削除時に unregistration に設定されます。
7.34. jUDDI での BPEL プロセスの登録
前提条件
- org.apache.juddi.v3.client.mapping
手順7.12 タスク
org.apache.juddi.v3.client.mapping
パッケージのコードを使用します。- 以下の呼び出しを行い、Web サービスのエンドポイントを非同期に登録します。
//Add the properties from the uddi.xml properties.putAll(clerk.getUDDINode().getProperties()); RegistrationInfo registrationInfo = new RegistrationInfo(); registrationInfo.setServiceQName(serviceQName); registrationInfo.setVersion(version); registrationInfo.setPortName(portName); registrationInfo.setServiceUrl(serviceUrl); registrationInfo.setWsdlUrl(wsdlURL); registrationInfo.setWsdlDefinition(wsdlDefinition); registrationInfo.setRegistrationType(RegistrationType.BPEL); registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo); Thread thread = new Thread(registration); thread.start();
RegistrationInfo.RegistrationType を RegistrationType.BPEL に設定します。
7.35. URLLocalizer インターフェイスおよび JBoss Enterprise SOA Platform
7.36. 動的 UDDI サービスルックアップ
7.37. Service Locator を使用したサービスバインディングの検索
前提条件
- サービスおよびポートの名前がすでに分かっている必要があります。
手順7.13 タスク
- サービスロケーターを使用してサービスバインディングを検索するには、次のコードを使用します。
ServiceLocator serviceLocator = new ServiceLocator(clerk, urlLocalizer, properties); String endPointURL = serviceLocator.lookupEndpoint(serviceQName, String portName);
注記各サービスを呼び出す前にルックアップを行うことの欠点は、パフォーマンスに悪影響を与えることです。
7.38. チュートリアル: jUDDI クライアントの使用
前提条件
- パブリッシャー (この場合は
root
) がサービスレジストリーにすでに存在することを確認します。
手順7.14 タスク
uddi-client
モジュールにあるサンプルコードを取得します。- レジストリーを呼び出して、認証トークンを取得します。(次のコードは、このモジュールの単体テストから取得したものです):
public void testAuthToken() { try { String clazz = ClientConfig.getConfiguration().getString( Property.UDDI_PROXY_TRANSPORT,Property.DEFAULT_UDDI_PROXY_TRANSPORT); Class<?> transportClass = Loader.loadClass(clazz); if (transportClass!=null) { Transport transport = (Transport) transportClass.newInstance(); UDDISecurityPortType securityService = transport.getSecurityService(); GetAuthToken getAuthToken = new GetAuthToken(); getAuthToken.setUserID("root"); getAuthToken.setCred(""); AuthToken authToken = securityService.getAuthToken(getAuthToken); System.out.println(authToken.getAuthInfo()); Assert.assertNotNull(authToken); } else { Assert.fail(); } } catch (Exception e) { e.printStackTrace(); Assert.fail(); } }
注記正常なレスポンスを取得するために、ルートパブリッシャーの正しい認証情報を提供していることを確認してください。
付録A 更新履歴
改訂履歴 | |||
---|---|---|---|
改訂 5.3.1-23.400 | 2013-10-31 | Rüdiger Landmann | |
| |||
改訂 5.3.1-23 | Thu Jan 10 2013 | David Le Sage | |
|