11.6 Finding Services

11.6.1 I-026: Searching for Web Services

@@Scenario: searching for services that can handle my locale or language preference.  See Sections "3.3.2.12 categoryBag", "F.2     Grouping categories" in the UDDI V3 Spec - use grouped categories in <categoryBag>.  UDDI has a geo3166 categorization scheme (uddi-org:iso-ch:3166:1999) to restrict to services to geographic regions, but no 3066 or 639 categorization to specify locale or language capabilities of a service.  See also Section 6      "General Keywords Taxonomy" ( http://uddi.org/taxonomies/UDDI_Taxonomy_tModels.htm#_Toc25463873).  Another option is WSDL as part of the UDDI description.

Repositories and search-able meta-data (such as UDDI [UDDI]) about Web services need to provide support for multiple language searches. Transport layer issues do not allow XML data structures to be used for resolution, except by reference (e.g. the receiver must down-load the WSDL asynchronously to "decode" the preference). Tags on this layer may be necessary in place of XML data structures. (@@rewrite)

@@Scenario - searching fdor Service Description using my language

Using xml:lang and multiple entries, a Service Provider can publish text information about their service in multiple languages.  The name, description, address, and personName UDDI elements MAY be adorned with the xml:lang attribute to indicate the language in which their content is expressed.  The policyDescription element contains a description of the effect of the policy implementation.  This element can be adorned with the xml:lang attribute and can appear multiple times to allow for translations of the policy description.  Providers are encouraged to do this for target language markets that their service may support.   

Ideally, the entity names in UDDI should also provide and Alternate Name in RFC-2277 default language, readable in English.  This provides a fall back mechanism to allow a search to identify services even if the named contents may be in a script that is not readable by the entity doing the search.

@@(From the UDDI Spec - candidate for GEO)

The following shows an example of romanization where the primary name of the business (a Chinese flower shop) is in Chinese, and its alternative name is a romanization:

<businessEntity . . . >

  ........

  <name xml:lang="zh">黄河花店</name>

  <name xml:lang="en">Huang He Hwa Dian</name>

    .....

</businessEntity>

The following shows an example of transliteration where the primary name of the business is in Chinese, and is a transliteration of its alternative English name:

<businessEntity . . . >

  ........

  <name xml:lang="zh">康柏電腦股份有限公司</name>

  <name xml:lang="en">Compaq Computer Taiwan Limited</name>

    .....

</businessEntity>

The <address> element, contained in the businessEntity structure, contains a simple list of <addressLine> elements.

To expose an address’ structure and meaning, virtual keyedReference elements are employed. This is done by adorning the <address> element with a tModelKey attribute and use of the keyName/keyValue attribute pair for each <addressLine> element.

Additionally, the UDDI Business Registry has a canonical tModel, ubr-uddi-org:postalAddress, that identifies a canonical postal address structure with common address sub-elements (e.g. states, cities).  This canonical address structure describes address data via name/code pairs, enabling each common address sub-element to be identified by name or code.

The following example XML fragment shows how the application of tModelKey, keyName and keyValue attributes to <address>, in conjunction with the use of address sub-element names and codes defined by the ubr-uddi-org:postalAddress tModel, allows the structure and meaning of a contact’s address within a businessEntity to be derivable programmatically:

<address useType=”Sales office” tModelKey=”uddi:ubr.uddi.org:postalAddress”>

  <addressLine keyName=”Street” keyValue=”60”>Alexanderplatz</addressLine>

   <addressLine keyName=”House number” keyValue=”70”>12</addressLine>

   …

   <addressLine keyName=”Country” keyValue=”20”>Deutschland</addressLine>

</address>

The following example XML fragment shows an address in two languages where the sequence of the address lines differ according to the language used.  With the use of keyName/KeyValue pair together with the codes assigned in the ubr-uddi-org:postalAddress tModel, it is possible to determine the address semantics programmatically in spite of the difference in address sequence :

<address useType=”Sales office” xml:lang="en" tModelKey=”uddi:ubr.uddi.org:postalAddress”>

   <addressLine keyName=”Floor” keyValue=”100”>7 F</addressLine>

   <addressLine keyName=”House Number” keyValue=”70”>No. 245 </addressLine>

   <addressLine keyName=”District” keyValue=”50”>Sec. 1</addressLine>

  <addressLine keyName=”Street” keyValue=”60”>Tunhua South Road</addressLine>

   <addressLine keyName=”City” keyValue=”40”>Taipei </addressLine>

</address>

</address><address useType=”Sales office” xml:lang="zh" tModelKey=”uddi:ubr.uddi.org:postalAddress”>

   <addressLine keyName=”City” keyValue=”40”> 台北市 </addressLine>

  <addressLine keyName=”Street” keyValue=”60”> 敦化南路</addressLine>

   <addressLine keyName=”District” keyValue=”50”> 一段</addressLine>

   <addressLine keyName=”House Number” keyValue=”70”> 245 號</addressLine>

   <addressLine keyName=”Floor” keyValue=”100”> 7 樓</addressLine>

   …

</address>

As there is a large variation in address sub-elements of different countries, the defined canonical address structure does not attempt to include all possible address sub-elements of all countries.  Freeform address lines are therefore supported in the <address> element.

The usage of the canonical address structure is optional, but recommended, for both publishers of business entities and developers of GUIs of UDDI publishing services.

The following shows an example of use of multiple name elements to support a multi-script language and also the use of acronym.  In the example, the first <name> element is the primary name of the business (a Japanese flower shop) in Japanese Kanji.  The second <name> element is the business’ name transliterated into Japanese Katakana.  The third <name> element gives the business’ full English name, and the fourth <name> element gives its English acronym:

<businessEntity . . . >

  ........

  <name xml:lang="ja">日本生花店</name>

  <name xml:lang="ja">ニッポンセイカテン</name>

  <name xml:lang="en">NIPPON FLOWERS </name>

  <name xml:lang="en">NF</name>

  .....

</businessEntity>

Where multiple name elements are published, the first name element is treated as the primary name, which is the name by which a business would be searched and sorted in the case of multiply-named businesses.  Client applications may use this knowledge to assist in optional rendering of a publisher’s primary name or all alternative names.