The localization support is built upon standard Java resource bundles and the JSP formatting tag library.

<webFramework>
    <encoding>
        <map locale="en" encoding="UTF-8"/>
        <map locale="zh" encoding="Big5"/>
    </encoding>
</webFramework>

The configuration files are localizable too. For example the file conf/bsc.xml has texts in the resource bundle com.systinet.uddi.bui.framework.BSCMessages.properties. The attributes like caption and hint have their localizable alternatives captionKey and hintKey, which have precedence over the original attributes providing text. The exception to this rule is the task element in the file conf/web_component.xml, where caption attribute has precedence over new captionKey attribute.

The localization of JSP files uses the standard formatting tag library. Every JSP must start with import of this library and setting of the locale for the current user, if he is logged in. The user's language is stored in the session variable userDefaultLanguage.

<%@ 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}"/>

In addition to the full power of the standard formatting library there are several Systinet extensions that complement localization needs.

<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}"/>

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

<syswf:localizedInclude baseName="publish/service/generic/selectInterfaces.html"/>

The localization of web applications uses standard resource bundles. It is necessary to use com.systinet.webfw.util.BundleHelper instead of java.util.ResourceBundle to retrieve a resource bundle otherwise different rules for locale selection will be used in the java code and JSP files, which results in page with portions in different languages.

The UDDI specification recognizes 4 entity types. However Business Service Console needs to present the UDDI data in terms of the user's business. Because of various mappings of resources, business artifacts etc. to UDDI, a single UDDI entity may correspond to several business-level entities.

The Entity Configuration defines how to recognize individual business artifacts. UDDI categorization is used to annotate the UDDI data with information about their role or type. So for example, a tModel is just a resource for the Business Service Console GUI. But when the tModel contains, for example, the uddi:uddi.org:resource:type category with value xslt, it represents an XSL Transformation document. Depending on business needs for the artifacts, different presentations, actions, or relationships may be available.

The Entity Configuration further specifies Views to be used for the particular entity. A View is a web page, or a portion of it, customized for the particular Entity. Views correspond to abstract operations that make sense on several entities. For example, pages for Delete action are different for Services and Providers but both pages perform the same abstract operation.

The configuration is stored in the file conf/bsc.xml, inside the entityViews element. New Entities can be created by adding new Entity definitions to that configuration, or behaviour of existing Entities can be changed. In this release, we support creation of new Entities and customization of Entities based on tModels (TM).

The following example shows a commented configuration of a "Categorization" entity, derived from a tModel. It corresponds to a taxonomy tModel used by the Registry. The individual parts of the configuration will be described below

<!--
    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>

The Business Service Console Entity definition element introduces a new Entity recognized by the Business Service Console. The entity has an id, a title, an optional description and an icon.

When the Business Service Console needs to print a noun, that describes a collection of entities, it uses the string denoted by the captionKey resource bundle key. In the case the Business Service Console needs to print a singular noun, which stands for the entity type, it uses the key with _single suffix. All strings are taken from the resource bundle src/BSCMessages.properties, unless specified otherwise by the captionKey attribute (see Business Service Console Localization for details).

The icon attribute is relative to directory webroot/gfx/tree. The icon is displayed in navigation trees to provide an unique visual appearance for the entity type.

<!--
    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>

As noted in the overview, an UDDI data structure may be used to represent several abstractions - Entities. An Entity is characterized by two things:

The basic UDDI type is one of:

The UDDI entity needs to be of the specified type in order to be recognized as the particular BSC Entity. In addition, you may specify mandatory keyedReferences, which the UDDI entity needs to have. The BSC Entity that has most keyedReferences matching the UDDI data will be selected. If there remains a choice, one is chosen at random.

Zero or more keyedReferences can be specified. When no categorization is present, all appropriate UDDI structures match, regardless of their contents. When specified, each keyedReference entry can have the following attributes:

<!--
    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>

	Note
	There must be an uncategorized Entity defined for each of the UDDI structures, to serve as a "catch-all" for data that does not match any specific entity. The default Business Service Console configuration provides such Entities.

A View stands for a visualization of some aspect, or an abstract task, that is available for the entity. Some tasks may or may not be available, depending on whether an appropriate View is available for the rendered data. The Business Service Console implementation uses View definitions to lookup tasks and components, which are appropriate for handling the data presentation, or to perform operations on the data.

A View is identified by a viewType. There can be at most one View for the particular viewType defined for the given entity. If such View is not defined, the Entity does not support the relevant visualization, or operation. The following table summarizes the supported viewTypes.

Each view can take some parameters. The parameters are passed by the code that invokes the View, and the framework passes them to the View's implementation component or task. The caller must be able to use the same parameters for invoking a View on different Entity types to remain independent of implementation details of individual Entities. To achieve this, the View definition not only contains parameter names, but also uses a simple mechanism to translate View's parameters to the implementation Component or Task parameters.

This is achieved by allowing JSTL EL expressions as parameter values. The parameter definition in the View configuration specifies the name of the parameter passed to the implementation Component or Task (paramName) and EL expression to construct the value from the parameter(s) passed by the caller (paramValue). Those EL expressions are evaluated in the context of a special component used to invoke Views, so all parameters, request and session variables can be used to create the resulting value.

The following example shows a definition for the "Detail" View for the "Service" entity. Note how the general "entityKey" parameter, which is applicable to all Detail Views, translates to a specific parameter of the particular implementation Task.

<!--
    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>

Entities may have some relationships or associations between them. An association between A and B is established by creating a keyedReference, with the tModelKey that identifies the type of the relationship and a keyValue which holds the entityKey of the other side of the association. Only directed associations between two UDDI entities are supported, however because of Registry query capabilities, it is also possible to navigate in the reverse direction of an association - and Business Service Console supports that with the "Referenced By" action.

A reference is defined by:

The Business Service Console presents References to other entities on Detail pages of entities, and provides "Referenced By" action for an entity to discover where the entity is referenced from. References defined in this configuration can also be added by the Business Service Console user using the Add Reference Wizard.

The following example shows how Policies can be associated with an arbitrary Entity. We define a reference to the "policy" entities, with a certain tModelKey (according to the WS-Policy specification), and we do not restrict who can use such a reference.

<!--
   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>

If a Component wants to smoothly integrate, it should ask the Entity Configuration to classify the data it works with. Then it can write proper nouns to the web page, and use tasks and components configured for the entity instead of using hardcoded links. The first step is obviously to find out what Entity the data correspond to.

In Java, you will use the EntityHelper to determine the classification:

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);

The code snipped provides you with an EntityHelper.Entity instance, which describes the data type. Please refer to API documentation for details how to use the retrieved data.

The EntityHelper API class is designed for simple usage from JSPs. For classification, you may use the following snippet:

<!--
    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}"/>

The bsc:setEntityClassification is a JSP alternative to call the findEntityByClassification method of the EntityHelper class. Note the usage of the bscEntityClassifier. This is session variable, provided by the Business Service Console Framework so the EntityHelper API is accessible from JSP pages.

If you are given an entityId instead of a data structure, you may easily refer to the EntityHelper.Entity instance using an EL expression in the 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]}"/>

In order to use the Entity's caption or description, the procedure described in Localization guide must be used, to make use of the appropriate localized string. We recommend using the following pattern:

<!--
    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>

The snippet first parses the resource bundle key provided as entity.captionKey property, then loads the appropriate ResourceBundle using the fmt:setBundle standard tag. Note the bundle key naming convention used to load the singular and plural nouns for the Entity type.

When working with some data structure, you may directly invoke a Component, using syswf:component, or make a link to a specific task using syswf:control. If you work on a mixture of data structures, each structure may require a different Component to display itself, or a different Task to perform the action. When the Entity Configuration changes, so that, for example, the task URI of the Edit operation changes, pages which use hardcoded component names or task URIs may become inconsistent with the rest of the UI.

You may perform the operation in an abstract way, using the invokeEntityView Component. You need to pass in enough information to identify the entity type and you need to specify the type of invoked View (see above for the overview of supported view types). Parameters defined by the View specification will be forwarded to the View component or task. You may pass additional parameters, but you have to prefix them with the prefix view_ so that they are recognized and forwarded.

<!--
    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>

<!--
    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>

You may also need to determine whether a certain View is available. The EntityHelper.Entity provides you with all supported views as a java.util.Map, so you use the contents from a JSP easily:

<!-- 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>

The presence of a View indicates, that a certain function is available for an entity. You may conditionally change the page appearance based on such an indication.

In places where an entity is mentioned, it is often appropriate to link to the entity Detail page. There is a special component showEntityName for this purpose. It renders the entity's name as a hyperlink to the entity's Details.

<!--
    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>

A description of the component and its parameters can be found in file jsp/browse/showEntityName.jsp, which you can find in bsc.jar or in the BSC work directory.

The API contains two important Java types. The first is the class com.systinet.uddi.bui.framework.component.util.permission.UserContext. An instance is created automatically, when a user logs into the Business Service Console and it is available in the global session under key userContext. The instance holds the groups that the user is member of and a list of his permissions.

Then there is an interface com.systinet.uddi.bui.framework.component.util.permission.DataFeeder. It is the developer's responsibility to create and feed an instance of its implementation. There are two implementations available. com.systinet.uddi.bui.framework.component.util.permission.UDDIDataFeeder is initialized with list of UDDI keys and it fetches specified UDDI structures from BEA AquaLogic Service Registry. If these structures are already available, then it is better to use com.systinet.uddi.bui.standard.component.util.permission.BuiDataFeeder for performance reasons.

To check user permissions in Java code you must use class com.systinet.uddi.bui.framework.component.util.permission.PermissionEvaluator. It contains public methods to check whether the user can create a business service in the given business entity, or binding template in the given business service, and to check whether the user can update or delete a specified business entity, business service, binding template or tModel. These methods take a UDDI key, the UserContext and a DataFeeder implementation as arguments.

boolean allowed = PermissionEvaluator.checkPermissionDeleteTM(tModelKey, userContext, dataFeeder);

To check user permissions in JSP, there is a tag checkPermission. In addition to a UDDI key, the UserContext and a DataFeeder implementation, it accepts operation and var attributes as arguments. It specified variable receives the result of the check.

<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>