ビジネス・サービス・コントロール・フレームワーク  目次

この項では、開発者の観点からビジネス・サービス・コントロール(BSC)について説明します。ビジネス・サービス・コントロール・フレームワークのアーキテクチャと構成、およびコンソールをカスタマイズする方法について説明します。

ビジネス・サービス・コントロールの実装および構成は、REGISTRY_HOME/app/uddiディレクトリにあるJARファイルbsc.jarに含まれています。

この項の内容は次のとおりです。

ビジネス・サービス・コントロールのローカライゼーション  ビジネス・サービス・コントロールまたはレジストリ・コントロールをローカライズする方法

ディレクトリ構造  bsc.jarのディレクトリ構造

ビジネス・サービス・コントロールの構成  bsc.jar内のビジネス・サービス・コントロール構成ファイル

パーミッションのサポート  操作を実行するパーミッションをユーザーが持っているかどうかを指定する機能

コンポーネントおよびタグ  ビジネス・サービス・コントロールのコンポーネントの開発に使用されるbsc.jar内のコンポーネントおよびタグ

ビジネス・サービス・コントロールのローカライゼーション  目次

Oracle Service Registryは、ローカライゼーションに対応しています。この項では、ビジネス・サービス・コントロールやレジストリ・コントロールなどのWebアプリケーションのローカライゼーションに焦点を当てて説明します。 Oracle Service Registryのローカライゼーション・サポートに関する情報、およびローカライズ可能なWebアプリケーションの作成方法について説明します。

基本概念  目次

ローカライゼーション・サポートは、標準のJavaソース・バンドルおよびJSP形式のタグ・ライブラリに基づいて構築されています。

ロケールの検出  目次

ユーザー言語検出ルーチンは、HTTPリクエストごとに起動されます。userAccountのlanguageCodeが設定されている場合、ユーザーがログインすると、userAccountのlanguageCodeが使用されます。設定されていない場合は、ブラウザの優先言語が使用されます。その後、システムによって、選択されたロケール用のリソース・バンドルが検索されるか、またはローカライズされたリソース・バンドルがない場合は、デフォルトのリソース・バンドルが使用されます。このアルゴリズムの詳細は、ResourceBundle JavaDocを参照してください。

デフォルトでは、UTF-8エンコーディングが使用されますが、web.xmlファイルにマッピングして、カスタムのロケール・エンコーディングが使用されるように構成できます。

<webFramework>
    <encoding>
        <map locale="en" encoding="UTF-8"/>
        <map locale="zh" encoding="Big5"/>
    </encoding>
</webFramework>
リソース・バンドル  目次

ディクショナリとして機能するすべてのJSPファイルに共通のリソース・バンドルが1つあります(com.systinet.uddi.bui.standard.BUIMessages)。このリソース・バンドルには、「OK」、「Cancel」またはエンティティの名前(プロバイダ、サービス)などの共通語に対するキーが含まれています。jspディレクトリ内の最上位ディレクトリごとに、そのファイルおよびサブディレクトリに対する一意のリソース・バンドルがあります。ビジネス・サービス・コントロール用のリソース・バンドルは、srcディレクトリにあり、構築フェーズ時にWASP-INF/classesディレクトリにコピーされます。

リソース・キーのネーミング規則  目次

リソース・キーは、JSPファイル名(接頭辞なし)およびラクダ記法による英語の識別子で構成されています。(単語の先頭に、空白またはアンダースコアではなく大文字が使用されます。)JSPファイルは、最上位ディレクトリのサブディレクトリの一部に保存され、そのサブディレクトリ名もリソース・キーにエンコードされます。たとえば、JSPファイルsearch/interfaces/simple.jspのリソースはcom.systinet.uddi.bui.standard.component.search.SearchMessages.propertiesファイルに保存され、すべてのキーにinterfaces.simple_という接頭辞が付けられます。

一部の構成ファイルでは、デフォルトのバンドルではなく、カスタムのリソース・バンドルを使用する必要があります。カスタムのリソース・バンドル名をリソース・キーにエンコードする方法が1つあります。リソース・キーに$という文字を含めると、その文字より前の部分はリソース・バンドルの識別子として処理され、リソース・キーの残りの部分が実際のリソース・キーとして処理されます。たとえば、customBundle$resourceKeyなどです。

構成のローカライゼーション  目次

構成ファイルもローカライズ可能です。たとえば、conf/bsc.xmlファイルの場合は、リソース・バンドルcom.systinet.uddi.bui.framework.BSCMessages.properties内にテキストがあります。captionhintなどの属性には、ローカライズ可能な代替属性(captionKeyおよびhintKey)があります。これらの代替属性は、テキストを入力すると元の属性より優先順位が高くなります。このルールには例外があり、conf/web_component.xmlファイルのtask要素では、caption属性が新しいcaptionKey属性より優先されます。

JSPローカライゼーション  目次

JSPファイルのローカライゼーションでは、標準形式のタグ・ライブラリが使用されます。すべてのJSPは、このライブラリのインポート、および現行のユーザーがログインしている場合はそのユーザー用のロケールの設定で開始される必要があります。ユーザーの言語は、セッション変数userDefaultLanguageに保存されています。

例21 ローカライゼーションの例

<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %>
<c:if test="${not empty globalSession['userName']}">
   <fmt:setLocale value="${globalSession['userDefaultLanguage']}" scope="page"/>
</c:if>
<fmt:setBundle basename="com.systinet.uddi.bui.standard.component.search.SearchMessages" var="search_Message"/>
<fmt:message key="interfaces.simple_operationProperty" bundle="${search_Message}"/>

標準形式のライブラリの強力な機能に加えて、ローカライゼーションの要件を補完するいくつかの拡張機能があります。

ParseResourceKeyタグ  目次

parseResourceKeyタグは、埋込みリソース・バンドルをリソース・キーに含めることができる場合に使用します。このタグによって、そのような状況が検出され、使用されるリソース・バンドルおよびリソース・キーの値を保持する新しい変数が2つ導入されます。

表80 ParseResourceKeyタグのパラメータ

パラメータ説明必須
key カスタムの埋込みリソース・バンドルを含めることができるリソース・キー はい
defaultBaseName カスタムのバンドルが検出されない場合に使用するデフォルトのリソース・バンドル はい
varBundle このリソース用のバンドルの名前を保持する変数の名前 はい
varResource リソース・キーを保持する変数の名前 はい

例22 ParseResourceKeyタグの使用例

<syswf:parseResourceKey key="${captionKey}"
    defaultBaseName="com.systinet.uddi.bui.framework.WebComponentMessages"
    varBundle="bundleName" varResource="finalCaptionKey"/>
<fmt:setBundle basename="${bundleName}" var="dynamic_Message"/>
<fmt:message key="${finalCaptionKey}" var="dialogCaption" bundle="${dynamic_Message}"/>
LocalizedFileNameタグ  目次

LocalizedFileNameタグでは、現行のロケール用にローカライズされたファイルの名前が検索されます。リソース・バンドルのロードの場合と同じ経験則的な検索が使用されます。たとえば、scripts.jsというファイルがあり、フランス語のロケールが設定されている場合は、scripts_fr.jsが戻されることがあります。

表81  localizedFileNameタグのパラメータ

パラメータ説明必須
basedir サーブレットのコンテキストからリソースにアクセスするためにfileNameに連結される接頭辞 はい
fileName ローカライズされたバージョンが必要なファイルの名前 いいえ
var 現行のロケール用のファイル名を保持する変数の名前 はい

例23 localizedFileNameの使用例

<syswf:localizedFileName basedir="/../webroot/" fileName="js/bui.js" var="jsBui"/>
                <script language="JavaScript" src="<c:out value="${jsBui}"/>"></script>
LocalizedIncludeタグ  目次

非常に長いテキストをローカライズする必要がある場合があります。特に、テキストに書式設定情報が含まれている場合は、そのテキストをリソース・バンドルにキーとして保存しても実用的ではありません。このような場合に対処するために、現行のロケールで選択されたファイルの内容を出力に書き込むlocalizedIncludeタグがあります。ファイル選択のルールは、リソース・バンドルの場合と同じです。

表82  localizedIncludeタグのパラメータ

パラメータ説明必須
baseName 出力に書き込まれるテキストを含むリソースへのパス はい

例24 localizedIncludeの使用例

<syswf:localizedInclude baseName="publish/service/generic/selectInterfaces.html"/>
Javaのローカライゼーション  目次

Webアプリケーションのローカライゼーションでは、標準のリソース・バンドルが使用されます。リソース・バンドルを取得するには、java.util.ResourceBundleではなく、com.systinet.webfw.util.BundleHelperを使用する必要があります。使用しない場合は、JavaコードおよびJSPファイルでロケールの選択に対して異なるルールが使用され、ページに異なる言語が含まれることになります。

エンティティの構成  目次

この項では、UDDIデータがビジネス・サービス・コントロールのエンティティとして認識されるように、ビジネス・サービス・コントロールを構成する方法、およびこれらのエンティティに対する標準アクションにフックする方法について説明します。

概要  目次

UDDI仕様では、4つのエンティティ・タイプが認識されます。ただし、ビジネス・サービス・コントロールでは、ユーザーの業務上の観点からUDDIデータを表現する必要があります。リソース、ビジネス・アーティファクトなどとUDDIとのマッピングは様々であるため、単一のUDDIエンティティが、複数のビジネス・レベルのエンティティに一致する場合があります。

エンティティの構成によって、個々のビジネス・アーティファクトを認識する方法が定義されます。UDDIのカテゴリ化は、ロールまたはタイプに関する情報を含むUDDIデータの注釈に使用されます。たとえば、tModelは、単なるビジネス・サービス・コントロールのGUI用のリソースです。ただし、たとえば、tModelにxsltという値を持つuddi:uddi.org:resource:typeカテゴリが含まれている場合、そのtModelはXSLTドキュメントを表します。アーティファクトに対するビジネス要件に応じて、様々な表現、アクションまたはリレーションシップが使用可能になります。

また、エンティティの構成によって、特定のエンティティに使用されるビューが指定されます。ビューとは、特定のエンティティ用にカスタマイズされたWebページまたはその一部のことです。ビューは、複数のエンティティで実行可能な抽象操作に対応しています。たとえば、「Delete」アクションのページは、サービスとプロバイダで異なりますが、いずれのページでも同じ抽象操作が実行されます。

構成  目次

構成は、entityViews要素内のconf/bsc.xmlファイルに保存されています。新しいエンティティの定義をその構成に追加して新しいエンティティを作成するか、または既存のエンティティの動作を変更できます。このリリースでは、新しいエンティティの作成およびtModel(TM)に基づいたエンティティのカスタマイズがサポートされています。

次の例では、tModelから導出された、カテゴリ化のエンティティの構成をコメント付きで示します。この例は、レジストリで使用される分類tModelに対応しています。構成の個々の部分の内容は次のとおりです。

例25 XML文書の定義

<!--
    Definition of a new entity, based on a TModel (TM). We specify an icon,
     a (localizable) name (caption) and (localizable) description.
-->
<entity entityId="xsd" type="TM" icon="xsd.gif"
    captionKey="bsc.entityViews_xsd_caption" descriptionKey="bsc.entityViews_xsd_description">
    <!--
        Categorization together with "type" attribute (above) tells the
        framework how to identify this type of entities
    -->
    <categorization>
        <keyedReference tModelKey="uddi:uddi.org:resource:type" keyValue="xsd"/>
    </categorization>

    <!--
        Views tells the BSC which components and tasks should be used
        to display information about the entity or to manipulate with
        the entity
    -->
    <views>
        <view type="list" task="/browse/resources/xsds">
            <parameter paramName="entityId" paramValue="${entityId}"/>
            <parameter paramName="editableMode" paramValue="${editableMode}"/>
        </view>
        <view type="listMy" task="/browse/resources/xsds">
            <parameter paramName="entityId" paramValue="${entityId}"/>
            <parameter paramName="editableMode" paramValue="${editableMode}"/>
            <parameter paramName="filterMyEntities" paramValue="true"/>
        </view>
        <view type="create" task="/publish/resources/xsds/createXSDResource">
            <parameter paramName="requiredCategories" paramValue="${categoryBag.KeyedReferenceArrayList}"/>
        </view>
        <view type="edit" task="/publish/resources/xsds/editXSDResource">
            <parameter paramName="tModelKey" paramValue="${entityKey}"/>
        </view>
        <view type="find" task="/search/resources/schemas">
            <parameter paramName="editableMode" paramValue="${editableMode}"/>
        </view>
        <view type="searchResults" component="resourcesXsdResults">
            <parameter paramName="query" paramValue="${query}"/>
            <parameter paramName="var" paramValue="${var}"/>
        </view>
        <view type="detail" task="/browse/xsdDetail">
            <parameter paramName="tModelKey" paramValue="${entityKey}"/>
        </view>
        <view type="treeContextMenu" component="contextMenu_xsdList"/>
        <view type="pageMenu" task="/catalog/xsdMenu"/>
        <view component="xsdsSubscriptionView" type="subscriptionChangeView"/>
        <view type="delete" task="/publish/resources/xsds/unpublishXSDResource">
            <parameter paramName="tModelKey" paramValue="${entityKey}"/>
        </view>
    </views>

    <!--
        References defines how to make associations with this type of entity,
        what keyedReferences to use and who can make the association
    -->
    <references>
        <!-- One or more references, leading to this entity type. -->
        <reference refName="schema"
                 captionKey="bsc.entityViews_xsd_refSchema_caption"
                 descriptionKey="bsc.entityViews_xsd_refSchema_description">
            <!-- originTypes may be either entityIds, or UDDI entity types.
                 No origin means all entities match
            <originType>xml</originType>
            -->
            <originType>xml</originType>
            <keyedReference tModelKey="uddi:uddi.org:resource:reference" keyName="definition"/>
        </reference>
        <reference refName="schemaOfSource"
                captionKey="bsc.entityViews_xsd_refSchemaOfSource_caption"
                descriptionKey="bsc.entityViews_xsd_refSchemaOfSource_description">
            <originType>xslt</originType>
            <keyedReference tModelKey="uddi:uddi.org:resource:reference"
                keyName="transformation-source"/>
        </reference>
        <reference refName="schemaOfDestination"
                captionKey="bsc.entityViews_xsd_refSchemaOfDestination_caption"
                descriptionKey="bsc.entityViews_xsd_refSchemaOfDestination_description">
            <originType>xslt</originType>
            <keyedReference tModelKey="uddi:uddi.org:resource:reference"
                keyName="transformation-destination"/>
        </reference>
        <reference refName="dependencyOnXSD"
                captionKey="bsc.entityViews_dependencyOnXSD_caption"
                descriptionKey="bsc.entityViews_dependencyOnXSD_description">
            <keyedReference tModelKey="uddi:systinet.com:dependency" keyName="tModel"/>
        </reference>
    </references>
</entity>

エンティティ定義  目次

ビジネス・サービス・コントロールのエンティティ定義の要素によって、ビジネス・サービス・コントロールで認識される新しいエンティティが導入されます。エンティティには、ID、タイトル、オプションの説明およびアイコンがあります。

表92 エンティティ定義の属性

属性説明必須
entityId このエンティティ・タイプを識別する一意の識別子。小文字で開始し、英数字の文字のみを使用する必要があります。 はい
captionKey この文字列は、エンティティ・キャプションに使用される実際の文字列に保存するリソース・バンドルへのキーとして機能します。単数形および複数形の処理については、後続の項を参照してください。 はい
descriptionKey エンティティ・タイプを簡単に説明する文字列に対するリソース・バンドルへのキー。この説明には、HTMLマークアップを含めることができます。 いいえ

ビジネス・サービス・コントロールでは、エンティティの集合を説明する名詞を出力する必要がある場合、captionKeyリソース・バンドル・キーで指定された文字列が使用されます。ビジネス・サービス・コントロールでは、エンティティ・タイプを表す単数形の名詞を出力する必要がある場合、_singleという接頭辞を含むキーが使用されます。captionKey属性で指定されないかぎり、すべての文字列はリソース・バンドルsrc/BSCMessages.propertiesから取得されます(詳細は、「ビジネス・サービス・コントロールのローカライゼーション」を参照)。

icon属性は、webroot/gfx/treeディレクトリに対して相対的です。アイコンは、ナビゲーション・ツリーに表示され、エンティティ・タイプの一意で視覚的な外観を指定するために使用されます。

例26 XML文書の定義

<!--
    The "XML Document" entity is derived from UDDI TModel.

    The definition also defines what name and icon should display for this
    type of data.
-->
<entity entityId="xml" type="TM" icon="xml.gif"
    captionKey="bsc.entityViews_xml_caption"  descriptionKey="bsc.entityViews_xml_description">
    <categorization>
        <!--
            "XML Documents" are characterized by a keyedReference for the
            uddi:uddi.org:resource:type taxonomy, with "xml" value.
        -->
        <keyedReference tModelKey="uddi:uddi.org:resource:type" keyValue="xml"/>
    </categorization>
</entity>
エンティティのカテゴリ化  目次

概要で示したとおり、UDDIデータ構造は、複数の抽象物(エンティティ)を表現する場合に使用できます。エンティティには、次の2つの特徴があります。

  • 基本UDDIタイプ

  • カテゴリ化

基本UDDIタイプは、次のいずれかです。

BE

ビジネス・エンティティ

BS

ビジネス・サービス

BT

バインディング・テンプレート

TM

tModel

UDDIエンティティは、特定のBSCエンティティとして認識されるには、指定したタイプである必要があります。また、UDDIエンティティで必要な必須のkeyedReferencesを指定できます。UDDIデータと一致するkeyedReferencesの大部分を含むBSCエンティティが選択されます。選択肢が残っている場合は、ランダムに1つが選択されます。

0(ゼロ)個以上のkeyedReferencesを指定できます。カテゴリ化が存在しない場合は、その内容に関係なく、すべての適切なUDDI構造が一致します。指定した場合は、各keyedReferenceエントリに、次の属性を含めることができます。

表93 keyedReference属性

属性説明必須
tModelKey カテゴリ化に使用される分類のtModelキー。 はい
keyName 必須のkeyedReferencekeyName。この属性を省略すると、keyNameが無視されます。 いいえ
keyValue 必須のkeyedReferencekeyValue。この属性を省略すると、(一致する場合でも)keyValueが無視されます。 いいえ

例27 XML文書の定義

<!--
    This is a definition of a WSDL service. It is derived from the Business
    Service UDDI structure (BS)
-->
<entity entityId="service" type="BS"  icon="service.gif"
    captionKey="bsc.entityViews_service_caption"
    descriptionKey="bsc.entityViews_service_description">
    <categorization>
        <!--
            A WSDL service is characterized by having the
            "uddi:uddi.org:wsdl:types" category with "service" value,
            according to the WSDL to UDDI mapping Technical Notes
        -->
        <keyedReference tModelKey="uddi:uddi.org:wsdl:types"
                        keyValue="service"/>
    </categorization>
</entity>

<!--
    This is a specification of a XSL Transformation entity. It is derived from
    a TModel UDDI structure (TM)
-->
<entity entityId="xslt" type="TM" icon="xslt.gif"
    captionKey="bsc.entityViews_xslt_caption"
    descriptionKey="bsc.entityViews_xslt_description">
    <categorization>
        <!--
            The XSLT resource is characterized by the resource:type
            category which must have the "xslt" value, according to
            the proposed mapping Technical Note.
        -->
        <keyedReference tModelKey="uddi:uddi.org:resource:type"
                        keyValue="xslt"/>
    </categorization>
</entity>

注意注意

特定のエンティティと一致しないデータがすべて検索されるようにするには、カテゴリ化されていないエンティティがUDDI構造ごとに定義されている必要があります。デフォルトのビジネス・サービス・コントロールの構成では、このようなエンティティが提供されます。

エンティティ・ビュー  目次

ビューは、一部の側面を視覚化したもの、またはエンティティで使用可能な抽象的なタスクを表します。レンダリングされたデータに対して適切なビューが使用可能かどうかによって、一部のタスクが使用できない場合もあります。ビジネス・サービス・コントロールの実装では、ビュー定義を使用して、データ表現の処理に適したタスクおよびコンポーネントの検索、またはデータ上での操作の実行を行います。

ビューは、viewTypeによって識別されます。指定したエンティティに定義された特定のviewTypeに対するビューは1つのみです。このようなビューが定義されていない場合、そのエンティティでは、関連する視覚化または操作がサポートされていません。次の表に、サポートされているviewTypesの概要を示します。

表94 事前定義されたビュー・タイプ

viewType説明必須
searchResults 特定タイプのエンティティに対して検索結果を戻す埋込み可能なコンポーネント。このコンポーネントでは、問合せが受け入れられ、一致する結果が画面上にレンダリングされますこれらのコンポーネントは、レポートやクイック検索などで使用されます。 いいえ
edit 特定のエンティティを編集するタスク。このタスクでは、エンティティ・キーが受け入れられ、エンティティの編集に適した画面(フォーム、ウィザード)が生成されます。 いいえ
detail エンティティの詳細情報を表示するタスクを指定します。このタスクでは、表示するエンティティのキーが受け入れられます。エンティティに関する情報にアクセスできるようにするには、このビューが必須です。 はい
find エンティティを検索するタスクを指定します。このタスクでは、フォームおよび検索結果が表示されます。 いいえ
subscriptionChangeView 特定のエンティティ・タイプのサブスクリプション結果をレンダリングするコンポーネントを指定します。このコンポーネントでは、パラメータとしてフィルタ処理および表示するサブスクリプションのリストが受け入れられます。 いいえ
create 新しいエンティティを作成するウィザードまたはフォームを含むタスクを指定します。このタスクによって、新しいエンティティが保存される親構造を識別するパラメータを処理できます。 いいえ
delete エンティティを削除するタスクを指定します。このタスクでは、パラメータとして単一のキーまたはキーの集合が受け入れられ、単一または複数のエンティティの削除が処理されます。 いいえ
list 特定タイプのすべてのエンティティを表示するタスクを指定します。このタスクでは、編集機能を有効/無効にするパラメータが受け入れられます。これらのタスクでは、ログインは必要ありません。 いいえ
listMy ログインしているユーザーが所有するタイプのすべてのエンティティを表示するタスクを指定します。指定しない場合は、listビューの機能と同じです。 いいえ
treeContextMenu カタログ・ツリーのコンテキスト・メニューを指定します。指定しない場合、エンティティのコンテキスト・メニューは表示されません。 いいえ
pageMenu エンティティがカタログ・ツリーで選択されている場合にエンティティのメニューを表示するタスクを指定します。指定しない場合、エンティティはカタログに表示されません。 いいえ

各ビューに、複数のパラメータを指定できます。パラメータは、ビューを起動するコードによって渡され、フレームワークによってビューの実装コンポーネントまたはタスクに渡されます。異なるエンティティ・タイプでのビューの起動を個々のエンティティの実装の詳細と無関係にするには、コール元で同じパラメータを使用できる必要があります。このためには、ビュー定義にパラメータ名を含めるのみでなく、単純なメカニズムを使用して、ビューのパラメータを実装コンポーネントおよびタスクのパラメータに変換します。

これは、パラメータ値としてJSTL EL式を許可することで実現できます。ビュー構成のパラメータ定義では、実装コンポーネントまたはタスクに渡されるパラメータの名前(paramName)、およびコール元によって渡されるパラメータから値を構成するEL式(paramValue)が指定されます。これらのEL式は、ビューの起動に使用される特別なコンポーネントのコンテキストで評価されるため、すべてのパラメータ、リクエストおよびセッション引数を結果の値の作成に使用できます。

次に、サービス・エンティティの詳細ビューの定義の例を示します。すべての詳細ビューに適した一般的なentityKeyパラメータを、特定の実装タスクの固有のパラメータに変換する方法に注意してください。

例28 Javaでのデータの種別

<!--
    We declare a view of type "detail", which is implemented by the
    Task /browse/serviceDetail
-->
<view type="detail" task="/browse/serviceDetail">
    <!--
        The implementation task accepts "serviceKey" parameter,
        we have to adapt the View's parameter to the custom name.
    -->
    <parameter paramName="serviceKey" paramValue="${entityKey}"/>
</view>

参照  目次

エンティティ間にいくつかのリレーションシップまたは関連がある場合があります。AとBとの関連は、リレーションシップのタイプを識別するtModelKeyおよび関連の反対側のentityKeyを保持するkeyValueを使用してkeyedReferenceを作成することで確立されます。2つのUDDIエンティティ間では、1方向の関連のみがサポートされています。ただし、レジストリの問合せ機能のため、反対方向の関連でもナビゲートできます。ビジネス、サービス・コントロールでは、「Referenced By」アクションの使用がサポートされています。

参照は、次の項目で定義されます。

refName

この参照を識別する識別子。

keyedReference

レジストリで関連を表す場合に使用されるkeyedReferencetModelKeyタグは必須で、keyNameタグはオプションです。keyedReferenceが存在する場合は、この参照を作成するために、keyedReferencekeyName値を指定する必要があります。

originType

0(ゼロ)個以上のoriginTypesを指定すると、関連を確立できるエンティティを制限できます。originTypeが存在しない場合は、いずれのタイプのエンティティも関連の生成元として機能できます。originTypeが存在する場合は、表示されたエンティティ・タイプのみが、関連の生成元として機能できます。複数のoriginType値がサポートされています。

指定可能な値は、エンティティ定義の属性idの値です。また、UDDI構造タイプを表す値(BE、BS、BT、TM)も指定できます。UDDI構造タイプを指定すると、そのUDDI構造から導出されたエンティティから参照を生成できます。

注意注意

使用可能な生成元は、リレーションシップ分類互換性リストのサブセットである必要があります。リレーションシップ分類との互換性がないUDDI構造を持つoriginTypeを使用可能にした場合、そのような参照(関連)をエンティティに追加することはできなくなります。

ビジネス・サービス・コントロールでは、エンティティの詳細ページに、他のエンティティへの参照があり、エンティティの参照元を検出する「Referenced By」アクションがエンティティに対して用意されています。また、ビジネス・サービス・コントロールのユーザーは、参照の追加ウィザードを使用して、この構成で定義される参照を追加できます。

次に、ポリシーを任意のエンティティと関連付ける方法の例を示します。(WS-Policy仕様に従って)特定のtModelKeyを使用してポリシー・エンティティへの参照を定義し、その参照を使用できるユーザーは制限しません。

例29 ポリシー・エンティティ

<!--
   Definition of the "Policy" entity
-->
<entity entityId="policy" type="TM" icon="policy.gif"
      captionKey="bsc.entityViews_policies" descriptionKey="bsc.entityViews_policies">
      <!-- Some categorization that identifies the entity -->
      <categorization>
         <keyedReference tModelKey="uddi:schemas.xmlsoap.org:policytypes:2003_03"
             keyValue="policy" keyName="policy"/>
      </categorization>
      <views>
         <!-- List of views, not important for this example -->
         ...
      </views>

      <references>
         <!--
            We define a Reference named "refLocalPolicy", with a (localizable) caption and description.
            originTypes specifier is missing, so this Reference can originate from any type of
            Entity.
         -->
         <reference refName="refLocalPolicy"
               captionKey="bsc.entityViews_policy_refLocalPolicy_caption"
               descriptionKey="bsc.entityViews_policy_refLocalPolicy_description">
            <!--
               This Reference will be stored using a keyedReference, that have tModelKey set
               to "uddi:schemas.xmlsoap.org:localpolicyreference:2003_03" and keyName set to
               "Associated Policy"
            -->
            <keyedReference tModelKey="uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"
               keyName="Associated Policy"/>
         </reference>
      </references>

</entity>

UDDIデータの分類方法  目次

コンポーネントを円滑に統合するには、処理するデータを分類するようにコンポーネントからエンティティ構成に要求する必要があります。その後、Webページに適切な名詞を書き込み、ハードコードされたリンクを使用するかわりに、エンティティに構成されたタスクおよびコンポーネントを使用できるようになります。最初のステップでは、データと対応するエンティティを検索します。

Javaでは、EntityHelperを使用して種別を決定します。

例30 Javaでのデータの種別

UDDIObject fromInstance;

/**
    Assume, that the "fromInstance" variable is initialized to an UDDIObject
    instance
 */

// Extract CategoryBag from whatever UDDI structure we have
CategoryBag fromCatBag = BscObjectUtilities.getCategoryBag(fromInstance, true);
// Get the list of KeyedReferences
KeyedReferenceArrayList fromKr = fromCatBag.getKeyedReferenceArrayList();
// Lookup the appropriate Entity definition from Entity Configuration
EntityHelper.Entity myEntity = helper.findEntityByCategorization(fromKr, fromType);

コード・スニペットには、データ型を記述するEntityHelper.Entityインスタンスが用意されています。取得されたデータの使用方法の詳細は、APIドキュメントを参照してください。

JSPページのエンティティの使用  目次

EntityHelper APIクラスは、JSPから簡単に使用できるように設計されています。種別に対しては、次のスニペットを使用できます。

例31 JSPでのデータの種別

<!--
    The "instance" variable should be initialized to some UDDIObject
    instance. The "entityType" variable will be created and set to the
    appropriate EntityHelper.Entity instance by the tag.
-->
<bsc:setEntityClassification var="entityType" instance="${instance}"/>

bsc:setEntityClassificationは、EntityHelperクラスのfindEntityByClassificationメソッドをコールするJSPの代替コードです。bscEntityClassifierの使用方法に注意してください。これは、EntityHelper APIがJSPページからアクセス可能になるようにビジネス・サービス・コントロールのフレームワークで提供されているセッション変数です。

データ構造ではなくentityIdが指定されている場合は、JSPでEL式を使用して、簡単にEntityHelper.Entityインタフェースを参照できます。

例32 JSPでのデータの種別

<!--
    The "entityId" variable should be initialized
    to one of the entity types as defined in bsc.xml

    The "bscEntityClassifier" contains a framework-provided instance
    of the EntityHelper API, which provides a Map of available entities
    for easy lookup from JSP.
-->
<c:set var="bscEntityType" value="${bscEntityClassifier.entities[entityId]}"/>

エンティティのキャプションまたは説明を使用するには、ローカライゼーション・ガイドで説明されている手順に従って、適切なローカライズ済の文字列を使用する必要があります。次のパターンを使用することをお薦めします。

例33 JSPでのデータの種別

<!--
    First, get the entity type for the given entityId, we are expected to
    work with
-->
<c:set var="bscEntityType" value="${bscEntityClassifier.entities[entityId]}"/>

<!--
    Handle embedded bundle path specification, see localization guide for
    the details. The evaluated bundle name and key name will be placed
    into named request variables
-->
<syswf:parseResourceKey key="${bscEntityType.captionKey}"
    defaultBaseName="com.systinet.uddi.bui.framework.BSCMessages"
    varBundle="bundleName" varResource="finalCaptionKey"/>

<!--
    Load the bundle, which actually contains the key.
    Note that the bundle name may not be known at design time,
    as it may be embedded in the generalized resource bundle key
-->
<fmt:setBundle basename="${bundleName}" var="dynamic_Message"/>

<!--
    Setup two variables, one holding plural noun for entity caption,
    the other will hold the singular
-->
<fmt:message key="${finalCaptionKey}" var="entityCaption"
             bundle="${dynamic_Message}"/>
<fmt:message key="${finalCaptionKey}_single" var="entityCaption_single"
             bundle="${dynamic_Message}"/>

<!--
    Finally, format some message (properly localizing it through a bundle),
    and substitute the entity nouns in it. Note that the message itself
    can control whether plural or singular is used - it can use {0} to denote
    plural and {1} for singular noun.
-->
<fmt:message key="some_message_key" bundle="${myBundle}">
    <fmt:param value="${entityCaption}"/>
    <fmt:param value="${entityCaption_single}"/>
</fmt:message>

このスニペットでは、最初にentity.captionKeyプロパティとして指定されるリソース・バンドル・キーが解析され、次にfmt:setBundle標準タグを使用して適切なResourceBundleがロードされます。エンティティ・タイプに対する単数形および複数形の名詞のロードに使用されるバンドル・キーのネーミング規則に注意してください。

ビューの使用  目次

データ構造を操作する場合は、syswf:componentを使用してコンポーネントを直接起動するか、またはsyswf:controlを使用して特定のタスクへのリンクを作成することができます。様々なデータ構造を組み合せて操作する場合は、各構造に、その構造自体を表示するための別コンポーネントまたはアクションを実行するための別タスクが必要なことがあります。たとえば、「Edit」操作のタスクURIを変更するためにエンティティの構成を変更した場合、ハードコードされたコンポーネント名またはタスクURIを使用するページと残りのUIとの一貫性がなくなる可能性があります。

invokeEntityViewコンポーネントを使用して、抽象的な方法で操作を実行することができます。エンティティ・タイプを識別するための十分な情報を渡し、起動されたビューのタイプを指定する必要があります(サポートされているビュー・タイプの概要は、前述の項を参照)。ビューの仕様で定義されているパラメータは、ビュー・コンポーネントまたはタスクに転送されます。追加パラメータを渡すこともできますが、そのパラメータが認識されて転送されるように、view_という接頭辞を付ける必要があります。

例34 エンティティ構成に構成されているコンポーネントの起動

<!--
    The following code invokes a "searchResults", which produces a table
    of results for the entity and the passed query.
    The code is taken out from Reports tab implementation
-->
<syswf:component prefix="${tabId}" name="invokeEntityView">
    <!--
        The desired viewType
    -->
    <syswf:param name="viewType" value="searchResults"/>
    <!--
        The query to process, taken from a prepared Map
        of queries for individual entity types
    -->
    <syswf:param name="query" value="${entityQueries[type.id]}"/>
    <!--
        Output parameter, component stores the result list in a temporary
        to allow the caller to find out whether the result list is
        empty
    -->
    <syswf:param name="var" value="references_tmp"/>
    <!--
        Propagates the type of the entity, to cover the case
        the view is reusable and is used for multiple entity
        types
    -->
    <syswf:param name="entityId" value="${type.id}"/>
</syswf:component>

例35 エンティティ構成に構成されているタスクへのリンク

<!--
    This snippet invokes a Create Wizard for the given entity.
-->
<syswf:component name="invokeEntityView" prefix="create">
    <syswf:param name="entityId" value="${entityId}"/>
    <syswf:param name="viewType" value="create"/>

    <!-- A HTML link will be generated -->
    <syswf:param name="mode" value="anchor"/>
    <!-- Text for the hyperlink -->
   <syswf:param name="caption" value="Link text"/>
</syswf:component>

特定のビューが使用可能かどうかを決定する必要がある場合もあります。EntityHelper.Entityでは、サポートされているすべてのビューがjava.util.Mapとして提供されているため、簡単にJSPから内容を使用できます。

例36 エンティティ構成に構成されているタスクへのリンク

<!-- Set the entity type into a variable, for convenience -->
<c:set var="bscEntityType" value="${bscEntityClassifier.entities[entityId]}"/>

<!-- Check whether the desired view is available -->
<c:if test="${not empty bscEntityType.views['create']}">
    <!-- Do some fancy stuff -->
    ...
</c:if>

ビューが存在している場合は、エンティティに対して特定の機能が使用可能であるということを示します。このような状況を示している場合は、ページの概観を条件付きで変更できます。

詳細ページへのリンク  目次

エンティティが記述されている場所は、多くの場合、エンティティの詳細ページへのリンクに適しています。この目的のために、showEntityNameという特別なコンポーネントがあります。このコンポーネントによって、エンティティの名前が、エンティティの詳細へのハイパーリンクとしてレンダリングされます。

例37 エンティティの詳細へのリンク

<!--
    This example shows how to create a link to the detail
    page of an Entity. The entity is given by its key,
    UDDI type and the keyedReferences.
-->
<syswf:component name="showEntityName" prefix="name1">
    <syswf:param name="entityKey" value="${key}"/>
    <syswf:param name="uddiType" value="TM"/>
    <syswf:param name="keyedReferences" value="${keyedReferenceArrayList}"/>
</syswf:component>


<!--
    The following example shows how to use UDDI structure itself,
    if it is available to link to the relevant entity detail
-->
<syswf:component name="showEntityName" prefix="n_${row.key}">
    <syswf:param name="entityInstance" value="${theStructure}"/>
    <!--
	We override the rendered string with a custom value.
	If this was omitted, the entity name would be printed
	as the hyperlink text
    -->
    <syswf:param name="instanceName" value="Some string"/>
</syswf:component>

コンポーネントの説明およびパラメータは、jsp/browse/showEntityName.jspファイルにあります。このファイルは、bsc.jarまたはBSCの作業ディレクトリにあります。

パーミッションのサポート  目次

ビジネス・サービス・コントロールでは、選択したオブジェクト上のユーザー・パーミッションの評価が強力にサポートされています。開発者は、現行のユーザーが一部のオブジェクトを操作できるかどうかを簡単に判別できます。この機能では、オブジェクトの所有権、アクセス制御リスト、グループおよびAPIのパーミッションが考慮されます。

データ・クラス  目次

APIには、2つの重要なJavaタイプがあります。1つ目は、クラスcom.systinet.uddi.bui.framework.component.util.permission.UserContextです。ユーザーがビジネス・サービス・コントロールにログインし、userContextキーの下のグローバル・セッションでインスタンスが使用できる場合は、インスタンスが自動的に作成されます。このインスタンスは、ユーザーが所属するグループおよびパーミッションのリストを保持します。

もう1つとしては、com.systinet.uddi.bui.framework.component.util.permission.DataFeederインタフェースがあります。実装のインスタンスを作成および入力するのは、開発者の責任です。 使用可能な実装は2つあります。com.systinet.uddi.bui.framework.component.util.permission.UDDIDataFeederは、UDDIキーのリストで初期化され、指定したUDDI構造がOracle Service Registryからフェッチされます。これらの構造がすでに使用可能な場合は、パフォーマンス上の理由から、com.systinet.uddi.bui.standard.component.util.permission.BuiDataFeederを使用することをお薦めします。

PermissionEvaluator  目次

Javaコードのユーザー・パーミッションをチェックするには、クラスcom.systinet.uddi.bui.framework.component.util.permission.PermissionEvaluatorを使用する必要があります。このクラスには、特定のビジネス・エンティティでユーザーがビジネス・サービスを作成できるかどうか、または特定のビジネス・サービスでバインディング・テンプレートを作成できるかどうかをチェックする公開メソッド、および指定したビジネス・エンティティ、ビジネス・サービス、バインディング・テンプレート、tModelをユーザーが更新または削除できるかどうかをチェックする公開メソッドが含まれています。これらのメソッドでは、UDDIキー、UserContextおよびDataFeederの実装が引数として受け入れられます。

例38 ParseResourceKeyタグの使用例

boolean allowed = PermissionEvaluator.checkPermissionDeleteTM(tModelKey, userContext, dataFeeder);
checkPermissionタグ  目次

JSPのユーザー・パーミッションをチェックするために、checkPermissionタグがあります。UDDIキー、UserContextおよびDataFeederの実装に加えて、operation属性およびvar属性が引数として受け入れられます。チェックの結果を受信する変数も指定されます。

表95  checkPermissionタグのパラメータ

パラメータ説明必須
var チェックの結果を保持する変数の名前。 はい
scope 新しい変数の有効範囲。 いいえ
operation 操作識別子。createeditまたはdeleteのいずれかです。 はい
key パーミッションをチェックするためのUDDI構造のキー。 はい
userContext ユーザー・アカウント固有のデータ用のコンテナ。ユーザーがログインしている場合は、通常、グローバル・セッションで使用できます。 はい
dataFeeder このページのUDDI構造に関する情報を保持するデータ・オブジェクト。 はい

例39 ParseResourceKeyタグの使用例

<bsc:checkPermission var="permission"
    operation="edit" key="${row.key}"
    userContext="${globalSession['userContext']}"
    dataFeeder="${dataFeeder}"/>
<c:if test="${permission}">
    <syswf:control targetTask="/publish/endpoints/editEndpoint"
            caption="Delete" mode="image" src="gfx/icon/i_edit.gif">
        <syswf:param name="bindingKey" value="${row.key}"/>
    </syswf:control>
</c:if>