ユーザーズ ガイド
|
 |
 |
|
Universal Description, Discovery and Integration (UDDI) レジストリは、企業で Web サービスを共有するために使用されます。UDDI サービスを使用することで、企業はこれらの Web サービスを整理およびカタログ化し、企業内または信頼できる外部のパートナと共有および再利用することができます。
Web サービスの UDDI レジストリ サービスは、次の URL にある UDDI 仕様で定義されています。
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3
この仕様は UDDI レジストリが準拠する規格で、UDDI を使用して Web サービスの情報をパブリッシュおよび検索する方法の詳細が記載されています。サービスの実行時の仕様は定義されません (単なるサービスのディレクトリです)。UDDI は、企業のビジネス、ビジネス サービス、および公開するサービスの技術的な詳細を分類するためのフレームワークを提供します。
レジストリへサービスをパブリッシュするには、サービス タイプと、レジストリ内でそのサービスを表すデータ構造の知識が必要です。レジストリ エントリには、特定のプロパティが関連付けられ、これらのプロパティ タイプはレジストリの作成時に定義されます。レジストリにサービスをパブリッシュして、他の組織がそのサービスを検出して使用できるようにすることが可能です。BEA AquaLogic Service Bus で開発されたプロキシ サービスは、UDDI レジストリにパブリッシュできます。AquaLogic Service Bus は、UDDI 3.0 準拠のすべてのレジストリに対応しています。BEA では、AquaLogic Service Registry を提供しています。
図 8-1 AquaLogic Service Bus と UDDI の統合
AquaLogic Service Bus で、AquaLogic Service Registry との Web ベース インタフェースを使用して、レジストリに簡単にアクセスして利用できます。AquaLogic Service Bus を UDDI と組み合わせて使用することにより、規格準拠の Web サービスの再利用が促進されます。この方法で、幅広いユーザが AquaLogic Service Bus リソースを検索および検出し、利用できるようになります。Web サービスと UDDI は一連の規格に基づいて構築されるため、再利用により、テストされ条件を満たした Web サービスやアプリケーション開発規格の使用が企業全体で促進されます。Web サービスとインタフェースは、タイプ、機能、または分類に応じてカタログ化すると、検索や管理がさらに容易になります。
UDDI は、HTTP、XML、XML Schema (XSD)、SOAP、WSDL などのさまざまな確立された業界標準に基づいています。UDDI 仕様の最新バージョンは、次の URL にあります。
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3
UDDI 仕様では、Web サービスのレジストリおよびそのプログラムのインタフェースについて記述されています。UDDI 自体が、Web サービスのセットです。UDDI 仕様は、以下に関する記述と検出をサポートするサービスを定義しています。
UDDI レジストリは、ビジネス サービスに関するデータとメタデータを格納します。これは、他のアプリケーションが検出および再利用できるように Web サービス情報をカタログ化および管理する、規格準拠のライブラリです。UDDI を使用することにより、コードの再利用が増えるなど、設計時にも実行時にも IT 管理者にとってさまざまな利点があります。開発者にも次のような利点があります。
UDDI は、特定のデータ モデルを使用して、組織とサービスを定義するエンティティを表します。図 8-2 は、異なる UDDI エンティティ間の関係を示します。
UDDI データ モデルと UDDI で使用されるエンティティの詳細については、BEA AquaLogic Service Registry 2.0 の『User's Guide』の「Introduction to BEA AquaLogic Service Registry」を参照してください。
AquaLogic Service Bus で UDDI レジストリを使用する前に、以下のタスクを実行する必要があります。
AquaLogic Service Bus は、UDDI (Universal Description, Discovery and Integration) バージョン 3 を完全準拠で実装したすべての UDDI レジストリと連携します。
AquaLogic Service Registry 2.0 は、バージョン 3 UDDI 準拠のレジストリであり、AquaLogic Service Bus との連携が確認されています。
バージョン 3 準拠の UDDI レジストリはいずれも、一度 AquaLogic Service Bus と連携するように設定すれば、AquaLogic Service Bus Console でアクセスできるようになります。次のような機能があります。
レジストリのコンフィグレーションと検索の方法、ビジネス サービスを AquaLogic Service Bus にインポートする方法、およびプロキシ サービスを UDDI レジストリにパブリッシュする方法の詳細については、『AquaLogic Service Bus Console の使い方』の「システムの管理」を参照してください。
BEA AquaLogic Service Registry は、UDDI バージョン 3 を完全準拠で実装したものであり、サービス指向アーキテクチャ (SOA) の重要なコンポーネントです。
注意 : AquaLogic Service Registry は、AquaLogic Service Bus に付属していません。Systinet および BEA から別途ライセンスを取得してください。
UDDI レジストリは、サービスの検索、サービスの呼び出し、およびサービスのメタデータ (セキュリティ、転送、またはサービス品質) の管理のための、規格準拠の基盤インフラストラクチャです。Registry Console を使用して、レジストリのコンテンツを参照およびパブリッシュできます。Registry Console は、管理者がレジストリ管理を行うための主要コンソールです。ALSR コンソールを起動するには、Web ブラウザで URL http://hostname:port/uddi/web を開きます。ホスト名とポートは、AquaLogic Service Registry のインストール時に定義されたものです。デフォルトのポートは 8080 です。AquaLogic Service Registry の管理 (特にレジストリのコンフィグレーションや、パーミッション、承認、およびレプリケーションの管理) の詳細については、BEA AquaLogic Service Registry の『Administrator's Guide』を参照してください。
UDDI を使用する利点を明確にする 2 つのビジネス シナリオの例を以下に示します。
このシナリオでは、AquaLogic Service Bus を使用して、レジストリからサービスをインポートし、そのサービスを AquaLogic Service Bus プロキシ サービスの一部として元のレジストリにパブリッシュする方法を説明します。
AquaLogic Service Bus に、UDDI レジストリからビジネス サービスをインポートします。メッセージ フローでビジネス サービスと通信するように、プロキシ サービスをコンフィグレーションします。プロキシ サービス自体を、元のレジストリにパブリッシュして、他の人が使用できるようにすることができます。
図 8-3 プロキシ サービスと UDDI レジストリの通信
このシナリオでは、AquaLogic Service Bus を使用するドメイン間デプロイメントを説明します。あるドメインの AquaLogic Service Bus アプリケーションが、実行時に他のドメインにある他の AquaLogic Service Bus サービスを呼び出す必要があります。
2 つのドメインに、AquaLogic Service Bus のインスタンスがそれぞれデプロイされています。ドメイン (D1) に AquaLogic Service Bus プロキシ サービス (P1) がコンフィグレーションされています。ドメイン (D2) の AquaLogic Service Bus プロキシ サービス (P2) が、プロキシ サーブビス (P1) にアクセスする必要があります。ドメイン間で直接通信することができないため、D2 の P2 は D1 の P1 を検出できません。AquaLogic Service Bus インポート/エクスポート機能は、別のドメインにあるサービスの実行時検出をサポートしていませんが、一般に公開されている UDDI レジストリにサービスをパブリッシュすることで、そのサービスがどのドメインにあっても検出できるようになります。P1 が UDDI レジストリに公開されると、実行時に呼び出したり (たとえば、株価を取得する)、他の AquaLogic Service Bus プロキシ サービスでビジネス サービスとしてインポートしたりできます。
異なるドメインからインポート/エクスポートする場合は、ネットワーク接続が必要です。プロキシ サービスが、異なるドメインのリポジトリにあるスキーマを参照するとします。この場合、URL を使用してインポートするために、そのドメインに HTTP でアクセスできる必要があります。接続がない場合は、エラー メッセージが返されます。
AquaLogic Service Bus Console を使用して以下のことが行えます。
図 8-5 は、AquaLogic Service Bus で UDDI を使用するための一般的なワークフローを示します。
UDDI レジストリをコンフィグレーションし、AquaLogic Service Bus で使用できるようにしたら、AquaLogic Service Bus プロキシ サービスをパブリッシュしたり、レジストリからビジネス サービスをインポートして、プロキシ サービスで使用したりできます。レジストリのコンフィグレーションは、AquaLogic Service Bus Console の AquaLogic Service Bus アクティブ セッション内で行う必要があります。
次の表は、UDDI レジストリのコンフィグレーションのプロパティを示しています。すべてのレジストリに、コンフィグレーションが必要な一連のプロパティがあります。UDDI レジストリをコンフィグレーションするときは、照会 URL が必要です。サービスをパブリッシュするときにレジストリへのアクセスが許可されるサービス アカウントも必要です。コンフィグレーション設定を指定するときは、次のようなケースがあります。
サービスを AquaLogic Service Registry にパブリッシュする場合、レジストリにアクセスするために、有効なユーザ名とパスワードで認証される必要があります。ユーザ名とパスワードは、資格を使用してサービス アカウント リソースとして AquaLogic Service Bus に実装されます。プロキシ サービスをコンフィグレーションする前に、サービス アカウントを定義しておく必要があります。それによって、プロキシ サービスのコンフィグレーションの際に、その認証条件でサービスを使用できるように設定されます。AquaLogic Service Bus にサービス アカウントを作成するには、『AquaLogic Service Bus Console の使い方』の「サービス アカウント」で「サービス アカウントの追加」を参照してください。
複数のユーザ名とパスワードを使用してレジストリを設定できます。これによって、異なるユーザがサービス アカウントに基づく異なるパーミッションを使用することができます。AquaLogic Service Registry のパーミッションは、管理者がユーザの権限を BEA AquaLogic Service Registry で管理し、さまざまなユーザ タイプのニーズに合わせたレジストリ ビューを作成するために開発されました。AquaLogic Service Bus に設定されたユーザ パーミッションによって、レジストリへのアクセス、レジストリのコンテンツ、および使用できる機能が規定されます。
AquaLogic Service Bus Console を使用して、プロキシ サービスを AquaLogic Service Registry にパブリッシュできます。このためには、AquaLogic Service Registry にアカウントを設定しておく必要があります。すべてのプロキシ サービスを UDDI レジストリにパブリッシュできます。表 8-3 に、サービス タイプと転送方式がリストされています。
どのビジネス エンティティでサービスをパブリッシュするかを選択できます。ビジネス エンティティの管理 (エンティティの作成、取り消し、更新、および削除) は、レジストリ ベンダが提供する管理コンソール (AquaLogic Service Registry の場合は、Business Service Console) を使用して行います。レジストリに最初にパブリッシュするときに、tModel をそのレジストリにロードする必要があります。これは、AquaLogic Service Bus Console でパブリッシュの詳細をコンフィグレーションするときに行います。UDDI レジストリへのパブリッシュ方法の詳細については、『AquaLogic Service Bus Console の使い方』の「システムの管理」で「UDDI レジストリへのプロキシ サービスのパブリッシュ」を参照してください。
AquaLogic Service Bus では、すべての UDDI バージョン 3 レジストリを使用できます。大規模な組織では一般に、システム管理者がレジストリの作成や設定を担当しています。サービス (AquaLogic Service Bus ではプロキシ サービス) をレジストリにビジネス エンティティとしてパブリッシュするには、サービス アカウントを設定する必要があります。
レジストリにあるサービスを AquaLogic Service Bus ビジネス サービスとしてインポートできます。WSDL ベースのサービスをインポートする場合、複数の UDDI バインディング テンプレートがあると、AquaLogic Service Bus はバインディング テンプレートごとに異なるビジネス サービスを作成します。
AquaLogic Service Bus のレジストリへのアクセスは、UDDI レジストリに対する AquaLogic Service Bus システム管理権限を持つユーザによって実現されます。レジストリのエントリは、自動的に AquaLogic Service Bus Console の [インポート] ページに表示されます。インポートする場合、利用できるレジストリのリストから選択します。レジストリのサービスを検出するには、特定のレジストリに問い合わせを行う必要があります。レジストリのエントリはユニークです。サービスをインポートするために使用するレジストリを指定する場合に、このクエリを実行します。
以下のタイプのビジネス サービスを UDDI レジストリから AquaLogic Service Bus にインポートできます。
AquaLogic Service Bus Console で UDDI レジストリからサービスをインポートする方法については、『AquaLogic Service Bus Console の使い方』の「システムの管理」で「UDDI レジストリからのビジネス サービスのインポート」を参照してください。
サービスが更新された場合、最新バージョンを取得するには、レジストリからサービスを再びインポートする必要があります。
サービスにはドキュメントが関連付けられており、これらのドキュメントには他のいくつかのドキュメント (スキーマ、ポリシーなど) が含まれる場合があります。インポートでは、UDDI レジストリはサービスの照会 URL に基づいてドキュメントの場所を示します。他のリソースを含むまたは参照するドキュメントが検索された場合、参照されているすべての情報および含まれている各項目が、個別のリソースとして AquaLogic Service Bus に追加されます。
レジストリのサービスを検索する条件として、ビジネス エンティティとパターンを使用します。たとえば、サービスを検索する場合、foo% と入力できます。AquaLogic Service Bus によってパブリッシュされたサービスには、サービスを識別する固有の tModel キーがあり、レジストリのサービスを検索するときに使用されます。
インポートするときにレジストリからビジネス エンティティのリストを取得しようとすると、自動的にレジストリに接続します。ビジネス エンティティがレジストリの構成の最上位ですが、他にもビジネス、アプリケーション タイプなどの検索条件を使用できます。認証が必要な場合は、ユーザ名とパスワードをシステム管理者から取得する必要があります。
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm にある技術ノート。最も重要な技術ノートの 1 つは、「Using WSDL in a UDDI Registry」です。http://uddi.org/solutions.html にある OASIS UDDI の「Solutions」ページを参照。http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm にある UDDI 仕様。
AquaLogic Service Bus プロキシ サービスの属性が、UDDI レジストリでサポートされるデータ モデルにマップされる必要があります。これによって、プロキシ サービスを UDDI ビジネス エンティティとしてパブリッシュできます。次の表は、AquaLogic Service Bus プロキシ サービスの UDDI レジストリ マッピングに関連する、サービス タイプ、メッセージ タイプ、および転送方式を示します。
|
|
||
プロキシ サービスは共通の属性を持ちます。また、サービスやサービスのタイプで使用される転送プロトコルによって固有に定義される属性もあります。各プロキシ サービスは、特定のタイプのメッセージを配信できます。
図 8-6 は、WSDL ベースのサービスが UDDI ビジネス エンティティにマップされる仕組みを示します。
図 8-6 WSDL サービスから UDDI へのマッピング
WSDL ベースのプロキシ サービスを UDDI レジストリにパブリッシュするためのベースとして、http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm にある技術ノート「Using WSDL in a UDDI registry, version 2.0.2」が使用されています。このドキュメントは、WSDL ベース以外のサービスをパブリッシュするための基準としても使用されます。このドキュメントと、ベースとなる UDDI 仕様は、UDDI エンティティの記述に使用される標準技術モデル (tModel) を記述しています。AquaLogic Service Bus プロキシ サービスを UDDI レジストリのエンティティとしてパブリッシュするには、AquaLogic Service Bus 固有の構成要素のいくつかをサポートするために標準 tModel を追加する必要があります。AquaLogic Service Bus プロキシ サービスのすべての属性を、サービス検索時に使用できるわけではありません (サービス タイプや転送の詳細など)。このような属性は、サービスを分類するものではなく、サービスについて知るために役立つ情報として、また、検出されたサービスのコンフィグレーションの詳細として使用されます。これらのコンフィグレーションの詳細は、ビジネス サービスのバインディング テンプレートの tmodelinstanceDetails セクションにマップされます。その他の属性は、サービスを個別に識別するものであり、サービスの検索条件として使用できます。これらの属性は、キー付き参照を使用して、バインディング テンプレートのカテゴリ バッグの値と共に tModel にマップされます。
AquaLogic Service Bus から UDDI へのマッピングの例を図 8-7 に示します。
図 8-7 AquaLogic Service Bus から UDDI へのマッピング
AquaLogic Service Bus プロキシ サービスの概要情報は、以下のようにビジネス サービスにマップされます。
businessService 要素にマップされる。uddi:bea.com:attributes:aqualogicservicebus です。uddi:bea.com:servicetype です。keyedReferenceGroup (名前 = "AquaLogicServiceBus"、値 = AquaLogic Service Bus インスタンスの URL) 内の keyedReference にマップされる。このインスタンスは、次の 2 つの目的を果たします。コード リスト 8-1 は、プロキシ サービスの概要情報のビジネス サービスへのマッピングを示します。
コード リスト 8-1 プロキシ サービスからビジネス サービスへのマッピング例
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="SOAP"/>
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://FOO02.amer.bea.com:7001"/>
</keyedReferenceGroup
注意 : プロキシ サービスをパブリッシュするときに作成される businessService のキーは、パブリッシュする側が割り当てたキー名です。これは、AquaLogic Service Bus のドメイン名、プロキシ サービスのパス、およびプロキシ サービス名から生成されます。形式は、uddi:bea.com:servicebus:<domainname>:<path>:<servicename> のようになります。
たとえば、AquaLogic Service Bus ドメインの AnonESB にプロジェクト Proxies があります。このプロジェクトに Accounting というフォルダがあり、このフォルダに PayoutProxy というプロキシ サービスが含まれます。PayoutProxy を UDDI にパブリッシュする場合、キー uddi:bea.com:servicebus:AnonESB:Proxies:Accounting:PayoutProxy で businessService が作成されます。
AquaLogic Service Bus プロキシ サービスの詳細情報は、以下のようにバインディング テンプレートにマップされます。
コード リスト 8-2 は、詳細情報のバインディング テンプレートへのマッピングを示します。
コード リスト 8-2 バインディング テンプレートへの詳細情報マッピングの例
<bindingTemplate bindingKey="uddi:" serviceKey="uddi:">
<accessPointuseType="endPoint">file:///c:/temp/in3</accessPoint>
<tModleInstanceDetails>
<tModleInstanceInfo tModelKey= "uddi:uddi.org:transport:file">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="fileMask" value="*.*"/>
<property name="sortByArrival" value="false"/> </ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
<tModleInstanceInfo tModelKey="uddi:bea.com:servicebus:protocol:
messagingservice">
<InstanceDetails>
<InstanceParms><ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema" value="http://domain.com:7001
/sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO"/>
<property name="responseType" value="None"/></ALSBInstanceParms>
</InstanceParms>
</InstanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
uddi:uddi.org:transport:* グループの転送方式のタイプごとに、異なる詳細メタデータのセットが含まれます (表 8-4 を参照)。このメタデータは、プロキシ サービスの転送のコンフィグレーション詳細を示します。これは、サービスの特徴を示したりサービスを問い合わせたりする場合に使用できるものではありませんが検出されたサービスにアクセスするときにこのデータが必要になります。メタデータは、XML 文字列で表され、tModelInstanceInfo の instanceParms フィールドに格納されます。
たとえば、HTTP 転送を使用するプロキシ サービスをマップし、HTTP コンフィグレーションの一部として、必要なクライアント認証や要求と応答の文字エンコーディングを含むコンフィグレーション詳細を記述する必要がある場合、bindingTemplate の tModelInstanceDetails の内容は以下のコード リストの例のようになる必要があります。
コード リスト 8-3 tModelInstanceDetails の例
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns="http://www.bea.com/wli/sb/uddi">
<property name="basic-auth-required" value="true"/>
<property name="request-encoding" value="iso-8859-1"/>
<property name="response-encoding" value="utf-8"/>
<property name="Scheme" value="http"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
注意 : 各転送方式のサービス エンドポイントは、必ず bindingTemplate の accessPoint フィールドに格納されます。
表 8-5 に、各転送方式で使用される tModelKey と InstanceParms が、転送方式のタイプごとにまとめられています。
|
|
accessPoint では、標準の mailto URL 形式である mailto:name@some_server.com が使用されます。これは、電子メールを読み取るための URL であり、AquaLogic Service Bus でプロキシ サービスにコンフィグレーションされたものとは異なります。サーバ名が不明な場合、この mailto URL をプロキシ サービス定義から生成することはできません。たとえば、プロキシ サービスが、POP3 サーバから読み取るように定義されている場合、mailfrom:pop3.bea.com などの URL で定義されているとします。このようなプロキシ サービスをパブリッシュすると、ダミー サーバが追加されます。上記の例では、パブリッシュされる URL は、mailto:some_name@some_server.com の形式になります。表 8-6 は、各サービス タイプの概要説明を示します。
|
|
|
|
|
|
|
|
|
|
|
AquaLogic Service Bus と UDDI のマッピングでは、AquaLogic Service Bus のメタデータと関係を表すいくつかの新しい標準 tModel が採用されています。このようなマッピングをサポートするために、これらの tModel を UDDI レジストリに登録する必要があります。管理者 ID を使用して、AquaLogic Service Registry にこれらの tModel を作成できます。
要求がスキーマを持つ XML で、応答がテキスト メッセージの、JMS で実行されるメッセージング サービスのマッピング例を以下に示します。
コード リスト 8-4 メッセージング サービスのマッピング例
<businessService
serviceKey="uddi:bea.com:servicebus:Domain:Project:JMSMessaging"
businessKey="uddi:9cb77770-57fe-11da-9fac-6cc880409fac"
xmlns="urn:uddi-org:api_v3">
<name>JMSMessagingProxy</name>
<bindingTemplates>
<bindingTemplate
bindingKey="uddi:4c401620-5ac0-11da-9faf-6cc880409fac"
serviceKey="uddi:bea.com:servicebus:
Domain:Project:JMSMessaging">
<accessPoint useType="endPoint">
jms://server.com:7001/weblogic.jms.XAConnectionFactory/
ReqQueue
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:jms">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms
xmlns="http://www.bea.com/wli/sb/uddi"><property name="is-queue" value="true"/>
<property name="request-encoding"
value="iso-8859-1"/>
<property name="response-encoding"
value="utf-8"/>
<property name="response-required"
value="true"/>
<property name="response-URI"
="jms://server.com:7001/
.jms.XAConnectionFactory/
RespQueue"/>
<property name="response-message-type"
value="Text"/>
<property name="Scheme" value="jms"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
<tModelInstanceInfo
tModelKey="uddi:bea.com:servicebus:
protocol:messagingservice">
<instanceDetails>
<instanceParms>
<ALSBInstanceParms xmlns=
"http://www.bea.com/wli/sb/uddi">
<property name="requestType" value="XML"/>
<property name="RequestSchema"
value="http://server.com:7001/
sbresource?SCHEMA%2FDJS%2FOAGProcessPO"/>
<property name="RequestSchemaElement"
value="PROCESS_PO_007"/>
<property name="responseType" value="Text"/>
</ALSBInstanceParms>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReferenceGroup tModelKey="uddi:bea.com:servicebus:properties">
<keyedReference tModelKey="uddi:bea.com:servicebus:servicetype"
keyName="Service Type"
keyValue="Mixed" />
<keyedReference tModelKey="uddi:bea.com:servicebus:instance"
keyName="Service Bus Instance"
keyValue="http://cyberfish.bea.com:7001" />
</keyedReferenceGroup>
</categoryBag>
</businessService>
|
|
|