Business Service Control Framework  Locate

This section describes the Business Service Control (BSC) from the developer's point of view. It describes the Business Service Control Framework architecture and configuration, and demonstrates how to customize the console.

The Business Service Control implementation and configuration are contained in the JAR file bsc.jar located in directory REGISTRY_HOME/app/uddi.

This section has the following subsections:

Business Service Control Localization  How to localize the Business Service Control, or the Registry Control.

Directory Structure  The directory structure of bsc.jar.

Business Service Control Configuration  Business Service Control configuration files in bsc.jar.

Permission support  Features to establish whether users have permission to perform operations.

Components and Tags  Components and tags in bsc.jar used to develop Business Service Control components.

Business Service Control Localization  Locate

Oracle Service Registry is ready for localization. This chapter is focused on localization of web applications such as the Business Service Control and Registry Control. It provides information on Oracle Service Registry localization support and how to write localizable web applications.

Basic concepts  Locate

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

Locale detection  Locate

The user language-detection routine is invoked for each HTTP request. When the user is logged in, the userAccount's languageCode is used, if it is set. Otherwise the browser's preferred language is used. The system then finds the resource bundle for the chosen locale or uses a default resource bundle, if there is no such localized resource bundle. See the ResourceBundle javadocs for details of the algorithm.

The system uses UTF-8 encoding by default, but it can be configured to use a custom locale-encoding mapping in the file web.xml:

        <map locale="en" encoding="UTF-8"/>
        <map locale="zh" encoding="Big5"/>
Resource bundles  Locate

There is one resource bundle common to all JSP files serving as a dictionary - com.systinet.uddi.bui.standard.BUIMessages. It contains keys for common words like "OK", "Cancel" or names of entities (Provider, Service). Then each top-level directory in the jsp directory has a unique resource bundle for its files and subdirectories. The resource bundles for Business Service Control are located within the src directory and are copied to the WASP-INF/classes directory during build phase.

Resource keys naming convention  Locate

The resource key is composed of JSP file name (without suffix) and an English identifier in camel notation. (Capital letters are used to indicate the start of words, instead of a space or underscore.) If the JSP file is located in some subdirectory of the top-level directory, the subdirectory name is also encoded in the resource key. For example resources for JSP file search/interfaces/simple.jsp are stored in the file and all keys have the prefix interfaces.simple_.

In some configuration files it is necessary to use a custom resource bundle instead of the default bundle. There is a way to encode the custom resource bundle name into the resource key. If the resource key contains the character $, then the part before it will be treated as the resource bundle identifier and the rest of the resource key as actual resource key. For example customBundle$resourceKey.

Localization of Configuration  Locate

The configuration files are localizable too. For example the file conf/bsc.xml has texts in the resource bundle 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.

JSP localization  Locate

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.

Example 21. Example of localization

<%@ taglib prefix="fmt" uri="" %>
<c:if test="${not empty globalSession['userName']}">
   <fmt:setLocale value="${globalSession['userDefaultLanguage']}" scope="page"/>
<fmt:setBundle basename="" 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 extensions that complement localization needs.

ParseResourceKey tag  Locate

The parseResourceKey tag is used, when the resource key can contain an embedded resource bundle. It detects such a situation and introduces two new variables that will hold the values of resource bundle and resource key to be used.

Table 80.  ParseResourceKey tag Parameters

key The resource key that may contain an embedded custom resource bundle. yes
defaultBaseName Default resource bundle to use if no custom bundle is detected. yes
varBundle Name of variable that will hold the name of the bundle for this resource. yes
varResource Name of variable that will hold resource key. yes

Example 22. ParseResourceKey tag - Usage Example

<syswf:parseResourceKey key="${captionKey}"
    varBundle="bundleName" varResource="finalCaptionKey"/>
<fmt:setBundle basename="${bundleName}" var="dynamic_Message"/>
<fmt:message key="${finalCaptionKey}" var="dialogCaption" bundle="${dynamic_Message}"/>
LocalizedFileName tag  Locate

LocalizedFileName tag finds the name of the localized file for the current locale. It uses the same heuristic search as resource bundle loading. For example if there is a file scripts.js and the french locale is set, then scripts_fr.js may be returned.

Table 81.  localizedFileName tag Parameters

basedir Prefix to be concatenated to fileName to access a resource from the servlet context. yes
fileName Name of file whose localized version is needed. no
var Name of variable that will hold the file name for the current locale. yes

Example 23. localizedFileName - Usage Example

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

Sometimes it is necessary to localize very long text and it would not be practical to store it in a resource bundle as a key, especially when the text contains formatting information. For this purpose there is a tag localizedInclude, which writes to output the content of file selected in the current locale. The rules for file selection are same as for Resource bundles.

Table 82.  localizedInclude tag Parameters

baseName Path to resource with the text to be written to output. yes

Example 24. localizedInclude - Usage Example

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

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.

Entity Configuration  Locate

In this section, we will explain how the Business Service Control can be configured to recognize UDDI data as Business Service Control Entities and how to hook into standard actions for those entities.

Overview  Locate

The UDDI specification recognizes 4 entity types. However Business Service Control 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 Control GUI. But when the tModel contains, for example, the 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.

Configuration  Locate

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

Example 25. Definition of an XML document

    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
        <keyedReference tModelKey="" keyValue="xsd"/>

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

        References defines how to make associations with this type of entity,
        what keyedReferences to use and who can make the association
        <!-- One or more references, leading to this entity type. -->
        <reference refName="schema"
            <!-- originTypes may be either entityIds, or UDDI entity types.
                 No origin means all entities match
            <keyedReference tModelKey="" keyName="definition"/>
        <reference refName="schemaOfSource"
            <keyedReference tModelKey=""
        <reference refName="schemaOfDestination"
            <keyedReference tModelKey=""
        <reference refName="dependencyOnXSD"
            <keyedReference tModelKey="" keyName="tModel"/>

Entity Definition  Locate

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

Table 92. Entity definition attributes

entityId An unique identifier that identifies this entity type. It should start with lowercase letter, and use only alphanumeric characters. Yes
captionKey This string serves as a key to the resource bundle, which stores to actual string used for the entity caption. See below regarding handling of singular and plural forms. Yes
descriptionKey The key into the resource bundle, for the string that provides a short decription of the entity type. The description may contain HTML markup. No

When the Business Service Control 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 Control 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/, unless specified otherwise by the captionKey attribute (see Business Service Control 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.

Example 26. Definition of a XML document

    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">
            "XML Documents" are characterized by a keyedReference for the
   taxonomy, with "xml" value.
        <keyedReference tModelKey="" keyValue="xml"/>
Entity Categorization  Locate

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

  • basic UDDI type

  • categorization

The basic UDDI type is one of:


Business Entity


Business Service


Binding Template



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:

Table 93. keyedReferenceAttributes

tModelKey A tModel key of the taxonomy used for categorization yes
keyName The keyName of the required keyedReference. If the attribute is omitted, keyNames are ignored. no
keyValue The keyValue of the required keyedReference. If the attribute is omitted, keyValues are ignored (any matches). no

Example 27. Definition of a XML document

    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"
            A WSDL service is characterized by having the
            "" category with "service" value,
            according to the WSDL to UDDI mapping Technical Notes
        <keyedReference tModelKey=""

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


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 Control configuration provides such Entities.

Entity Views  Locate

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

Table 94. Predefined View types

searchResults Embeddable component, that provides a search results for a given type of Entity. The Component should accept a query, and render the matching results on the screen. These Components are used in Reports, Quicksearch etc. No
edit Task for editing a specific entity. The task accepts an entity key, and produces a screen (form, wizard) suitable for editing the entity. No
detail Provides a task that displays detailed information for an entity. The task accepts the key of the entity to display. This View is mandatory to ensure that information about any entity can be reached. Yes
find Provides a searching task for the entity. The task is supposed to display a form and results of the search. No
subscriptionChangeView Provides a Component to render subscription results for the particular entity type. The Component accepts the list of subscriptions to filter and display as a parameter No
create Provides a Task with a Wizard or a form to create a new entity. The Task may process a parameter that identifies a parent structure where the new entity should be stored. No
delete Provides a Task for deleting the entity. The Task should accept a single key, or a collection of keys as a parameter, and it should handle deletion of a single or several entities. No
list Provides a task, which displays all entities of the particular type. The Task accepts a parameter, which turns edit functions on/off. These tasks should not require login. No
listMy Provides a task, which displays all entities of the type owned by the logged-in user; otherwise, the function is just as with the list view. No
treeContextMenu Provides a context menu for the Catalog tree. If missing, there will not be a context menu for the entity. No
pageMenu Provides a Task that displays the entity's menu when the Entity is selected in the Catalog tree. If missing, the entity will not be shown in Catalog at all. No

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.

Example 28. Classification of data in 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}"/>

References  Locate

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 Control supports that with the "Referenced By" action.

A reference is defined by:


An identifier that identifies this reference.


A keyedReference which is used to represent the association in the Registry. The tModelKey is mandatory, the keyName tag is optional: if present, the keyedReference must have such keyName value in order to form this reference.


Zero or more originTypes can be specified to restrict which Entities can establish associations. If no originType is present, the association can originate at any type of entity. When originType is present, only the listed entity types can serve as origins for the association. Multiple originType values are supported.

The permitted values are the values of the id Entity definition attribute. In addition, values that represent the UDDI structure types are permitted (BE, BS, BT, TM). When an UDDI structure type is specified, the Reference can originate from any entity derived from that UDDI structure.


The permitted origins should be a subset of the relationship Taxonomy compatibility list. If you permit an originType, whose UDDI structure is incompatible with the relationship Taxonomy, you will not be able to add such references (associations) to entities.

The Business Service Control 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 Control 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.

Example 29. Policy Entity

   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 -->
         <keyedReference tModelKey=""
             keyValue="policy" keyName="policy"/>
         <!-- List of views, not important for this example -->

            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
         <reference refName="refLocalPolicy"
               This Reference will be stored using a keyedReference, that have tModelKey set
               to "" and keyName set to
               "Associated Policy"
            <keyedReference tModelKey="" 
               keyName="Associated Policy"/>


How to classify UDDI data  Locate

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:

Example 30. Classification of data in Java

UDDIObject fromInstance;

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

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

Using Entities in JSP pages  Locate

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

Example 31. Classification of data in 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}"/>

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

Example 32. Classification of data in 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:

Example 33. Classification of data in 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}"
    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"
<fmt:message key="${finalCaptionKey}_single" var="entityCaption_single"

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

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.

Using Views  Locate

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.

Example 34. Invoking a Component configured in Entity Configuration

    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[]}"/>
        Output parameter, component stores the result list in a temporary
        to allow the caller to find out whether the result list is
    <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
    <syswf:param name="entityId" value="${}"/>

Example 35. Linking to a Task configured in Entity Configuration

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

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:

Example 36. Linking to a Task configured in Entity Configuration

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

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.

Linking to a Detail page  Locate

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.

Example 37. Linking to entity 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}"/>

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

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.

Permission support  Locate

Business Service Control contains powerful support for user permission evaluation on selected objects. The developer can easily find out, if the current user is allowed to manipulate some object. This feature takes into consideration object ownership, Access Control Lists, groups and API permissions.

Data classes  Locate

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 Control 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 Oracle 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.

PermissionEvaluator  Locate

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.

Example 38. ParseResourceKey tag - Usage Example

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

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.

Table 95.  checkPermission tag Parameters

var Name of the variable that will hold the result of the check. yes
scope Scope for the new variable. no
operation Operation identifier. One of create, edit and delete. yes
key The key of the UDDI structure for which we want to check permissions. yes
userContext Container for user account specific data. Typically available in global session, if the user is logged in. yes
dataFeeder Data object holding information about UDDI structures on this page. yes

Example 39. ParseResourceKey tag - Usage Example

<bsc:checkPermission var="permission"
    operation="edit" key="${row.key}"
<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}"/>