カテゴリー化の概要

IBM版のUniversal Description, Discovery and Integration (UDDI) Business Registryに登録されるビジネスには、ビジネスの名前 (考えうるあらゆる言語での名前)、住所、連絡先 (すべてのEメール・アドレス、電話、携帯電話、およびFAXの番号などを含む) など、膨大な量の読み取り可能な情報が含まれることがよくあります。サービス・プロバイダーは、それらのビジネスを記述し終えると、提供するすべてのサービスを追加します。そこで、会社は、そのすべての情報を集めれば、顧客が会社のドアをたたいて、会社のEメール受信箱をあふれさせるのを悠然と眺め、どんどん集まってくるオンラインの注文をただ見ていればいいのでしょうか？

いいえ、必ずしもそうではありません。会社は、UDDIで提供される最重要の機能の1つを利用する必要性があるのです。そう、カテゴリー化です。

企業が一般的に入力する情報だけでは、顧客は、「名前による検索」サーチを使用して、すでに知っているビジネスやサービスの名前によってしかそれらの情報を見付けられません。そのため、電話帳の紙のホワイト・ページおよびイエロー・ページをいまだに使う人たちだけしか、それらのビジネスを見付けられないと思われます。グローバルなビジネス・ディレクトリーでは、企業名の頭を "AAA" するだけで、その企業をリストの冒頭に掲載されるようにしたり、多くの人に見付けてもらえるように期待できない、ということが明白です。

UDDIには、標準の分類体系を組み込むためのメカニズムが用意されています。このメカニズムを使用して、必要なだけの業界標準の検索項目を使用して各項目を記述できます。それぞれのビジネス、サービス、または技術モデルに、キーによる参照 (つまり、カテゴリー化コード、ロケーター、またはキーワード) を保持する「カテゴリー・バッグ」を入れることができます。これによって、そのビジネスのタイプ、物理位置、および提供する正確な製品およびサービスをも特定して記述できます。このようなキーによる参照には、種別システムや分類体系の参照、その分類体系内の値が入っているテキスト・フィールド、および人間が読むことのできる説明のためのテキスト・フィールドが、含まれます。このカテゴリー化方式を使用して、UDDI Inquiry APIは迅速かつ効率的に、ビジネスとサービスを必要としているまさにその顧客に、ビジネスとサービスを結び付けることができます。

上に戻る

カテゴリー化の効果的な使用

UDDIでは現在、公開や照会で使用できるいくつかの「標準装備」のカテゴリー化システムをサポートしています (リンクは参考文献を参照)。

1. North American Industrial Classification System (NAICS)
   • ビジネス分類コード。例えば、Pharmaceutical Manufacturing (3254)、Optical Goods Stores (44613)
2. Universal Standard Products and Services Classification (UNSPSC)
   • 製品コードおよびサービス・コード。例えば、Ultra Light Aircraft (25.13.20.05.00)、Soil Pollution Advisory Services (77.12.16.04.00)
3. Geographic Classification System (GCS) (ISO 3166-1999ベース)
   • 国コード、州コード、地方コード、および地域コード。例えば、United States-Texas (US-TX)、Denmark (DK)
4. UDDI種別
   • UDDI標準の種別およびUDDIが使用/認識する標準の種別。例えば、Wire/Transport Protocol (トランスポート)、WSDL (wsdlSpec) で記述したWebサービス
5. 一般キーワード
   • キーワードへの任意の値のフリー・フォームの関連。例えば、"Store Location" (#102)、"Automobile" (Toyota)

上記の分類体系のうち最初の3つは、項目をカテゴリー化するための標準です。4番目の分類体系であるUDDI種別は、Webサービスの技術情報をカテゴリー化するための有用な値を提供するため、UDDI仕様の一部として開発された分類体系です。最後の分類体系は、キーワードを項目に関連付ける場合にとりわけ有用です。特に、項目の名前の一部になっていないキーワードの関連付けの場合に役立ちます。これらのカテゴリー・システムのそれぞれが、tModel (Technical Model) と呼ばれるUDDI項目によって一意的に識別されます。また各システムを、そのtModelKeyを使用して参照することができます。UDDIデータ構造での上記のカテゴリー情報の参照を、リスト1 にXMLで示しています。

                
<categoryBag>
  <keyedReference
   tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
    keyValue="3254"
    keyName=" Pharmaceutical Manufacturing " />
  <keyedReference
    tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634"
    keyValue="25.13.20.05.00"
    keyName="Ultra Light Aircraft" />
  <keyedReference
    tModelKey="UUID:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88"
    keyValue="US-TX"
    keyName="Texas" />
  <keyedReference
    tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
    keyValue="wsdlSpec"
    keyName="Specification for a Web Service described in WSDL" />
  <keyedReference
    tModelKey="aaa"
    keyValue="102"
    keyName="Store Location" />
</categoryBag>

これらの「標準装備」の値セットのほかにも、政府およびビジネスのほとんどの分野 (例えば、農業、自動車部品取扱店、コンピューターなど) で、それぞれ独自の標準および種別システムを開発すると考えられますが、それらのシステムを容易に、UDDIで公開、記述、参照できます。詳細および新規の値セットの公開に関するコード・サンプルについては、「Web Services Publication and Discovery」 (リンクは参考文献を参照) のUDDI4Jセクションを参照してください。

他の値セットを収めるため、UDDIでは、カテゴリー化、種別、および分類体系を提供する外部プロバイダーが自身の値セットをUDDIに登録するための手段も用意しています。それによって、すべてのビジネス、サービス、または技術モデルがそれらの値を「カテゴリー・バッグ」に関連付けることができるようにしています。

UDDIにはさらに、UDDIレジストリーと統合して、ビジネスまたはサービスがそれらの値を正確に関連付け、登録されていることを検証するための値セットのメカニズムも用意されています。プロバイダーは、それらの値セットからのコードが公開される前にUDDIが使用することのできる、検証サービスを配置することができます。

上に戻る

外部的に検査されるカテゴリー・システムの仕様

UDDIレジストリーで、外部検証サービスがある検査済みの分類体系の参照を受け取ると、該当する外部サービスにvalidate_values メッセージを発行します。これによって、所定のカテゴリー・システムの使用を外部組織により調整することができます。通常の使用では、特定のカテゴリー値が (指定されているkeyValue属性値の検査によって) 指定された分類体系内に存在することを確認することです。特定のカテゴリーおよび識別子について、検証サービスを提供する組織では、メッセージ内に渡されたIDや、その他の受け渡されたデータを用いたコンテキストを基にして、値の使用をさらに特定の組織に限定することができます (「Programmer's API」のリンクは、参考文献を参照)。

validate_values を呼び出すUDDIレジストリーの実装は、この呼び出しの唯一の引数として、businessEntity、businessService、またはtModel要素を渡します。これは、save_business、save_service、またはsave_tModel API呼び出し内で渡されるデータと同じです。同一タイプの複数の要素を一緒に渡すことができます。

UDDI V2スキーマ (リンクは参考文献を参照) を使用した、SOAP:Body内のvalidate_values API構文は、リスト2 に示すとおりです。

                
<complexType name="validate_values">
   <choice>
      <element ref="uddi:businessEntity" minOccurs="0" maxOccurs="unbounded" />
      <element ref="uddi:businessService" minOccurs="0" maxOccurs="unbounded" />
      <element ref="uddi:tModel" minOccurs="0" maxOccurs="unbounded" />
   </choice>
   <attribute name="generic" type="string" use="required" />
</complexType>

上に戻る

Speed-start検証サービス

Speed-start検証サービスは、IBM UDDI Test Registryに公開されたエンティティーに、アクセス可能なWebサービスが含まれていることを確認するときに役立ちます。IBM UDDI Test Registryは、developerWorksによる分類tModelがカテゴリー・バッグが入っているようなエンティティーの公開を要求されると、Speed-start検証サービスを起動します。その後この検証サービスは、エンティティーに提供されているすべてのSOAPエンドポイントとWSDL文書が、ワールド・ワイド・ウェブでアクセス可能であるかどうかを検査します。

Speed-start検証サービスは、UDDI V2仕様で記述されたUDDI V2validate_values APIの実装です。

developerWorksカテゴリー・システムの参照が入っている公開要求を実行する前に、その要求のエンティティーで最初に、Speed-start検証サービスによる検証を渡す必要があります。developerWorksカテゴリー・システムのキーは、IBM Webサービス・ツールに組み込まれています。あるいは、IBM UDDI Test Registryでカテゴリー・システムに対してfind_tModel 要求を発行することで取得できます。developerWorksカテゴリー・システムの参照は、エンティティーの中に次のようなXMLフラグメントとして現れます (リスト3 を参照)。

                
<categoryBag>
...
<keyedReference
  tModelKey="UUID:8F497C50-EB05-11D6-B618-000629DC0A53"
  keyValue="Speed Start"
  keyName="Web service information for the developerWorks Speed Start community" />
...
/categoryBag>

テスト・レジストリーは、validate_values 要求を含むSOAPメッセージを通知することで、Speed-start検証サービスを起動します。それらの要求には、businessEntity、businessService、またはtModelエンティティーのリストが含まれます。Speed-start tModelへのカテゴリー化が収められているすべてのエンティティーは、その検証サービスによる検証を受けます。

エンティティーに含まれているすべてのURLがワールド・ワイド・ウェブでアクセス可能な場合、エンティティーは有効と見なされます。URLが無効と判別されると、検証サービスは、エラー・コードとメッセージが入っている応答をテスト・レジストリーに送信します。その結果、UDDI公開要求は失敗し、検証側から公開元にエラー・コードとメッセージを返します。検証に成功したときは、成功応答がテスト・レジストリーに送信され、UDDI公開要求が成功します。

上に戻る

検証サービスの実装

Speed-start検証サービスは、Webサービスとして実装されます。Webサービスとは、インターネット接続によって他のアプリケーションになんらかの機能性を提供する、自己記述型で、自己完結した、アプリケーション・ロジックのモジュラー単位です。アプリケーションは、各Webサービスがどのように実装されているかについてなにも意識せずに、HTTPやXMLなどのWebプロトコルおよびデータを介して、Webサービスにアクセスします。

検証サービスは、UDDI V2validate_values APIを実装します。この実装では、Javaサーブレットを使用してvalidate_values 要求を処理します。サーブレットとは、WebSphere Application ServerなどのWebサーバー内で実行されるJavaプログラムです。サーブレットは、Webクライアントからの要求の受信と、それへの応答を、通常はHTTPによって行います。

validate_values APIを提供するサービスを実装するための方法はいくつかあります。AXISは生成したWSDL2Javaコードを使用して、UDDIスキーマからのデータ・タイプおよび、具体的なvalidate_values APIの実装用のベースとして使用できるインターフェースが生成されます (WSDL2Javaについての情報へのリンクは、参考文献を参照)。生成済みの検証値コードは、コード生成プログラムに渡される命名パラメーターに応じて、リスト4 のコードに類似したものになるはずです。

                
// An interface will be created, for which a concrete implementation can be written:
public interface UDDI_ValueSetValidation_PortType extends java.rmi.Remote
{
   public uddi.DispositionReport validate_Values(uddi.Validate_Values body);
}

このツールを使用する利点は、インターフェースによって参照されるデータ・タイプが、コード生成の一部として、すべてJavaクラスとして作成されることです。実行時に、これらのデータ・クラスは、インスタンス化され、またvalidate_values APIが起動されるたびに、AXISによる移植を受けます。Javaデータ構造の例として、リスト5 に、すべてのget/setメソッドを除いたuddi.vs.Validate_Values オブジェクトを示しています。

                
public class Validate_Values  implements java.io.Serializable {
    private uddi.AuthInfo authInfo;
    private uddi.BusinessEntity[] businessEntity;
    private uddi.BusinessService[] businessService;
    private uddi.BindingTemplate[] bindingTemplate;
    private uddi.TModel[] tModel;
    private uddi.PublisherAssertion[] publisherAssertion;
...

WSDL2Javaツールを使用すると、SOAP、HTTP、またはデータ・タイプのマッピングの処理を明示的に書くことなく、サービスの迅速な開発が可能になります。validate_values サービスの具体的な実装では、データ・タイプ配列のそれぞれをたどり、最上位のエンティティー、businessEntity、businessService、bindingTemplate、tModel、またはpublisherAssertionのコンテキストで検証されるデータを検索します。

完全なSOAPエンジンを使用せずに検証サービスを実装するもう一つの方法は、J2EEから抽象クラスHttpServletを拡張するJavaクラスを作成する方法です。UDDI APIは、HTTP Post要求に応答する必要しかないので、ValidationサービスはdoPostメソッドを実装するだけです。リスト6 は、これを表すサンプル・コードです。

                
public class ValidatorService extends HttpServlet
implements DefaultHandler
{
  protected boolean insideOverviewURL;
  protected StringBuffer overviewURL;
  protected void doPost(HttpServletRequest req,
  HttpServletResponse resp)
  throws ServletException, java.io.IOException
  {
    // Get the input stream
    InputStream input = req.getInputStream();
    // Read the XML request from the input stream
    // Parse the XML request using SAX and a registered listener
    // to examine specific elements, or use a DOM parser
    // to create a full document
    boolean validURLs = true;		
    try
  {
              SAXParser parser = new SAXParser();
              parser.setContentHandler(this);
              InputSource is = new InputSource( input );
              parser.parse( is );
      // Perform some contextual validation
      // Get the output stream
  }
    catch (SAXException e)
  {
      validURLs = false;
  }
    OutputStream output = resp.getOutputStream();
    output.setContentType("text/xml;charset=UTF-8");
    // Print the response to the output stream
    if (validURLs)
      // Print the SOAP message with E_success report
      output.write(UTF8_SUCCESS_RESPONSE_BYTES);
            else
      // Write the SOAP message with E_invalid value
      output.write(UTF8_INVALID_RESPONSE_BYTES);
  }
...
        // DefaultHandler methods for SAX parsing
    public void startElement(String uri, String localName,
    String qName, Attributes attributes)
    throws SAXException
    {
       	if (localName.equals("overviewURL"))
    {
              insideOverviewURL = true;
              overviewURL = new StringBuffer();
    }
    }
    public void characters(char[] ch, int start, int length)
    throws SAXException
    {
       	if (insideOverviewURL)
    {
              overviewURL.append(ch, start, length);
    }
    }
    public void endElement(String uri, String localName, String qName)
    throws SAXException
    {
       	if (insideOverviewURL
    {
              insideOverviewURL = false;
              // Throw an exception that will cause parsing to stop
              // on any inaccessible overviewURL
              if (!validateURL(overviewURL.toString()))
              throw new SAXException("Invalid overviewURL");
    }
    }
}

このサービスはXercesを使用して、XML要求の構文解析を行い、その要求の関連する部分のJavaオブジェクト表現をインスタンス化します。上記の例では、XML要素ローカル名 "overviewURL" を持つエンティティーのみを調べます。完全な検証サービスでは、メッセージ全体で、Speed-start tModelへのカテゴリー化が入っているUDDIを検索し、すべてのURLが検査されます。リスト7 の以下のコード断片は、URLがインターネットでアクセス可能であることを検証する方法を表しています。

                
private boolean validateURL( String urlString )
{
  boolean valid = true;
  try
  {
    URL url = new URL( urlString );
    URLConnection connection = url.openConnection();
    connection.connect();
  }
  catch ( MalformedURLException exception )
  {
    valid=false;
  }
  catch ( IOException exception )
  {
    valid=false;
  }
  return valid;
}
	

エンティティーがdeveloperWorks分類体系への参照を組み込むたびに、この実装が起動されるので、その分類体系の参照が入っているサービスに対する照会では、インターネットでアクセス可能なSpeed-startコミュニティーの一部であるレジストリー・データのサブセットが得られるはずです。

上に戻る

WebSphere Studio Web Services Explorerを使用した、Speed-startコミュニティーへの公開およびそこからの照会

Speed-startコミュニティーへのWebサービスの公開は、developerWorksカテゴリー・システムをサービスのプロパティーとして追加することのできる、任意のUDDIを認識するツールを使用して行うことができます。WebSphere StudioのWeb Services Explorerは、developerWorksカテゴリー・システムを組み込むように事前構成されています。公開側または照会側の観点からみれば、外部的に検査または検証されたカテゴリー・システムを使用したデータの区別は、UDDIのその他のカテゴリー・システムを使用する場合と同じです。

例として、developerWorksの "Ask the magic eight ball" 記事(参考文献を参照) で取り上げられているMagic 8 ball Webサービスを考えてみましょう。このWebサービスは、インターネット上にデモンストレーションとしてホストされ、次のURLでWSDLを使用して記述されています: http://dwdemos.alphaworks.ibm.com/axis/services/urn:EightBall?wsdl

このWebサービスをSpeed-startコミュニティーの一部として登録する際に行わなければならないのは、WSDLファイルのURLを調べること、およびそのWSDLファイルおよびサービス・エンドポイントがすでにインターネットにホストされていることを確認することのみです。

Web Services Explorerを使用して公開するには、WebSphere Studioで「File => Export... 」メニューを選択します。表示されたこのダイアログの先頭ページで、エクスポート宛先としてWebサービスを選択します。2番目のページでは、図1 に示されているようなIBMテスト・レジストリーを選択します。

次のステップは、画面の「Actions」セクションで公開ボタンを選択することで、サービスを提供するビジネス (またはプロバイダー) についての情報を作成することです。図2 に示すとおりです。

表示されたページで、ユーザー・アカウント情報 (アカウントは、https://uddi.ibm.com/testregistry/registry.htmlで取得できます)、およびビジネスまたはサービス・プロバイダーの名称と説明を入力します。

次の最終ステップでは、サービス情報を指定し、Speed-startコミュニティーの一部としてこれを検証する必要があることを示すカテゴリー項目を追加します。このため、図3 に示されているように、「Actions」セクションでサービス公開ボタンを選択します。

フォームが表示されたら、「Advanced」オプションを選択し、WSDLファイルの名前およびURLを入力します。図4 に示すとおりです。

サービスをSpeed-startコミュニティーの一部にすることを指示するため、該当するカテゴリー化を追加します。それには、カテゴリーを追加し、タイプのドロップダウン・ボックスから「dwCommunity」を選択し、「Browse...」 (図5 を参照) をクリックし、分類体系ブラウズ・ウィンドウから「Speed-start」を選択します。この情報の入力後、「Go」をクリックします。サービスは、インターネットでのアクセスが可能であることがSpeed-start検証サービスによって検査済みになると、公開されます。

このエクスプローラーを使用して、Speed-start検証サービスにより検証済みになっているすべてのサービスを検索するには、図6 に示すように、「Find」アクションを選択します。

検索ページが表示されたら、「Search for」ボックスから「Services」を選択し、検索のタイプとして「Advanced」を選択し、公開ステップで示したとおり、Speed-startのカテゴリー値を追加し、「Go...」をクリックします。

左側に示される結果は、Speed-startコミュニティーの一部としてサブミット済みのWebサービスのリストになります。図7 に示すとおりです。

上に戻る

結論

この記事では、カテゴリー化の一般的な概要を示し、UDDIレジストリーによって呼び出される検証サービスとともにカテゴリー化を使用して、カテゴリー・システム特有の基準に従ってコミュニティーまたは検証済みの結果のセットを提供する方法を説明しました。Speed-startコミュニティーの例は、特定のカテゴリーまたは識別子システムを参照するデータに対する照会の結果の質を著しく強化できる、コンテキスト検証サービスの能力を表すシンプルな実例といえます。この記事に記載した情報を使用すれば、サービス品質または参照サービスなど、UDDIレジストリーからの結果を大幅に強化するサービスを開発することが可能になります。

参考文献

• Webサービスの作成および配置のために必要なすべての情報は、developerWorksのSpeed-start Web services から取得できます。
  
  
• 「標準装備」のカテゴリー化システムについての詳細を参照してください。
  
  
• UDDI4J section of the Web Services Publication and Discovery (PDF) をお読みください。
  
  
• Programmer's API についての詳細を入手してください。
  
  
• UDDI V2 schema をダウンロードしてください。
  
  
• Doug TidwellのAsk the magic eight ball、(developerWorks、2003年1月) をお読みください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• カテゴリー化の概要
• カテゴリー化の効果的な使用
• 外部的に検査されるカテゴリー・システムの仕様
• Speed-start検証サービス
• 検証サービスの実装
• WebSphere Studio Web Services Explorerを使用した、Speed-startコミュニティーへの公開およびそこからの照会
• 結論
• 参考文献
• 著者について
• コメント