8 Managing Foundation Services

This chapter includes the following sections

Section 8.1, "Overview of the Foundation Management"
Section 8.2, "Logging In to the Foundation Manager"
Section 8.3, "Managing Devices"
Section 8.4, "Managing Transformers"
Section 8.5, "Managing Adapters"
Section 8.6, "Managing Regions"
Section 8.7, "Managing Digital Rights Policies"
Section 8.8, "Managing API Scan Policies"

8.1 Overview of the Foundation Management

The Foundation Manager enables you to create and modify such objects as devices, transformers, adapters, regions, digital rights policies, and API scan policies in the OracleAS Wireless repository. Table 8-1 describes these objects.

Table 8-1 Objects Created and Managed Using the Foundation Manager

Object Type	Description
Device	A device object associates a physical device or an abstract device with a transformer through user agents and MIME types. A device object captures the device attributes, which are used by both the multi-channel server and the messaging server.
Transformer	A transformer converts the content returned by the OracleAS Wireless adapters. Transformer types include: Result transformers, which convert Adapter Result content into SimpleResult content. Device transformers, which convert SimpleResult content into the final target format. A device transformer can be either the default transformer for a virtual device, or a custom transformer, which is used to render a specific application for a specific physical device.
Adapter	Adapter objects represent the OracleAS Wireless interface to content sources. Adapter objects have an attribute called `classes`, which identify the archive file that contains the actual Java implementation of the adapter.
Regions	OracleAS Wireless uses regions to enable developers to assign a location to an application, making the application location-based, unique to a specified area.
Digital Rights Policy	A digital rights policy specifies the execution (or usage) policy of J2ME applications (MIDlets) after users download them. For example, if a downloaded MIDlet can be executed only twice, then you package that application with a digital rights policy to assure that it is executed only twice. Other digital rights policies can be time-based, limiting the execution of MIDlets to prescribed time periods, and be of varying complexity.
API Scan Policy	An API scan policy specifies invalid API calls within J2ME application to the API scan process, which certifies J2ME applications (MIDlets).The invalid APIs are defined with package names, class names and method names in the API scan policy object.

The Foundation Manager provides a set of wizards that enable you to create these objects quickly and with a minimum of information. Each of these wizards break down the creation process into series of steps.

8.2 Logging In to the Foundation Manager

To use the Foundation Manager, you must first access the login page using the following URL:

http://<host>:<port>/webtool/login.uix

For example, you access the login page by entering the following URL into a browser:

http://hostname:7777/webtool/login.uix

Note:

7777 is the default port number for Oracle Application Server Wireless.The port number range is 7777 to 7877. To ensure that you are using the correct port number, check the port number for Oracle Application Server Wireless stored in [Oracle home]/install/portlist.ini. For more information on port usage, see the Oracle Application Server Administrator's Guide

Enter your user name and password. If you are an administrator, enter orcladmin as your user name. (The password is set during installation, but can be changed from the User Manager.)

After you successfully login, select the Foundation tab, the Foundation Manager's browsing page appears. From the Foundation Manager, you can administer the following repository objects:

Devices
Transformers
Adapters
Regions
Digital Rights Policies
API Scan Policies

The Foundation Manager provides a tab for each of these repository objects. Each has a browsing page, which enables you to search for an object, as well as access to functions for creating, editing, deleting, and testing.

8.3 Managing Devices

A device is an object in the OracleAS Wireless repository that represents either a physical device, such as a Nokia mobile phone, or an abstract device, such as e-mail, which link OracleAS Wireless transformers and the runtime device by recognizing the user-agent, the MIME type, and other HTTP headers.

HTTP headers enable a repository device to map to an actual device. Through the repository device, the OracleAS Wireless Server determines the appropriate transformer for rendering the device result for a variety of browsers, voice gateways, or message clients. For example, if the OracleAS Wireless Server recognizes a device with multi-media display capability, the XMS center (XMSC) renders the multi-media messages bound for the device in images rather than in plain text. Likewise, when delivering a J2ME MIDlet application to a user device, the J2ME provisioning server delivers a version the MIDlet application which is appropriate to the device.

The Devices tab enables you to create a device in the repository. Clicking this tab invokes the device browsing page (Figure 8-1), which displays a list of devices in the repository. From this page, you can search for, create, clone, delete, and edit a device.

Figure 8-1 The Browse Devices Page

Description of "Figure 8-1 The Browse Devices Page"

8.3.1 Searching for a Device

From the device browsing page, you can search for devices by keyword, name, manufacturer, model, user agent, or transformer.

To search for a device:

Select one of the following search options:

Name
Manufacturer
Model
Transformer
User Agent

Enter the keyword for your search.

Click Go. The Search Results page appears (Figure 8-2).

Figure 8-2 The Search Results Page (for Devices)

Description of "Figure 8-2 The Search Results Page (for Devices) "

8.3.2 Creating a Device

The device creation wizard enables you to create a device by prompting you through each step in the creation process. The wizard dedicates a page to each of these steps; you progress through the wizard by clicking Next after completing each step. At any point in the wizard, you can click the Back button to return to the preceding pages to change values. You can skip any of the pages in this wizard which contain parameters which do not apply to the device. After you have entered the required information, click Finish to complete the device.You can also edit the device to add, remove, or change the parameter values.

To access the wizard, click Create in the device browsing page. The wizard appears, defaulting to its first page, where you enter the basic information for the device.

Step 1: Entering the Basic Information for the Device

The Basic Info. page (Figure 8-3) enables you to define the general information of the device, such as the device name. Table 8-1 describes the parameters of the Basic Info. page.

Table 8-2 Parameters of Basic Information Page

Parameter	Value
Name	The name of the device. This name must be unique. This is a required value.
Description	A description of the device.
Manufacturer	The manufacturer of the device. If the manufacturer does not appear on the list, then enter the name of manufacturer and then click Add. The manufacturer then appears on the list, enabling you to select it.
Model	The model number of the device.

Figure 8-3 Entering the Basic Information for a Device

Description of "Figure 8-3 Entering the Basic Information for a Device"

Step 2: Setting the Transformers

Clicking Next in the Basic Info. page invokes the Transformer page (Figure 8-4). Using this page, you add the transformers and all of the appropriate user agents to the device.

To add user agents, enter the user agents supported by the device and then click Add. Continue until you have added all possible user agents for the device. You then select the user agents supported by the device by using the Move or Move All functions (> and >>) to transfer the user agents from the Available pane to the Selected pane.

To select transformers for the device, use the Move or Move All functions (> and >>) to shuttle the transformers from the Available List pane to the Selected List pane.

Click Next after you have selected the user agents and transformers to continue to the next step of the wizard where you device capabilities. Click Finish to complete the device.

Figure 8-4 Selecting User Agents and Transformers

Description of "Figure 8-4 Selecting User Agents and Transformers"

Step 3: Setting Device Capabilities

Device capabilities are categorized into several groups, including general device attributes (media type, display, text input), browser attributes, messaging attributes, voice-grammar attributes, and J2ME attributes (Figure 8-5). OracleAS Wireless examines the values for the device capabilities during the runtime, when the OracleAS Wireless Server renders the device-oriented markup languages, provisions J2ME applications, or sends device-oriented messages. For the detailed explanation of the syntax and semantics of device capabilities, refer to the description of device network adaptation included in the Oracle Application Server Wireless Developer's Guide.

Tips:

Although the device creation wizard provides separate pages for the device capabilities, none of these related parameters are required; you can successfully complete a device if you do not define any of these parameters.
To help you enter the values for the device capabilities parameters, the Device Capabilities pages include in-line help as hints under each of the inputting fields.You can also refer to the online help. On any of the Device Capabilities pages, you can click Finish to complete the device and skip the remaining steps.

Figure 8-5 Entering Device Capabilities -- Entering the General Device Features

Description of "Figure 8-5 Entering Device Capabilities -- Entering the General Device Features"

Step 4: Setting the Device Code Segment

Using the Device Code Segment page (Figure 8-6), you enter the device result prolog, the login page, and the error page.

For the device result prolog, you enter the code segment which is added to all the rendering results for this device. Entering a login page replaces the device's default login page. Likewise, entering an error page replaces the default error page for the device. Click Finish to complete the device

Figure 8-6 Entering the Device Result Prolog, Login and Error Pages

Description of "Figure 8-6 Entering the Device Result Prolog, Login and Error Pages"

8.3.2.1 Editing a Device

The Edit button in the device browsing page enables you to edit all of the information of a device. To edit a device, first select the device and then click the Edit button. The editing page appears and defaults to the parameters defined for the basic information of the device (Figure 8-7). You can select other device properties by selecting the appropriate links in the menu on the left side of the editing page. Click Apply to save any changes that you make to the parameters. Clicking Cancel returns you to the device browsing page.

Refer to the steps described in Section 8.3.2 for descriptions of the parameters for creating a device.

Figure 8-7 Editing a Device

Description of "Figure 8-7 Editing a Device"

8.3.2.2 Deleting a Device

You delete devices from the repository by selecting a device from the browsing page and then clicking Delete.

8.3.3 Cloning a Device

The Clone function enables you to create a new a new device with properties similar to an existing device; the new device inherits all of the capabilities from the existing device from which it was copied. Unlike creating a new device as described in Section 8.3.2, you need only enter a name for the device.You can later edit the parameters for the cloned device.

To clone a device, you select a device from the browsing page and then click Clone. Enter a name for the new device and then click Finish.

8.4 Managing Transformers

Clicking the Transformers tab displays the browsing page for transformers, which includes a table that lists the current transformers in the repository by name, object ID in the repository, the MIME type supported by the transformer, and the Simple Result format DTD version. Figure 8-8 illustrates this browsing page.

Figure 8-8 The Browse Transformers Page (Partial View)

Description of "Figure 8-8 The Browse Transformers Page (Partial View)"

From this page you can delete, edit, and create transformers.

8.4.1 Creating a Transformer

To create a transformer, click the Create Transformer button to invoke the Create Transformer page (Figure 8-9). To complete the transformer, you must define the following parameters, described in Table 8-3 and then click Finish.

Table 8-3 Parameters of the Create Transformer Page

Parameter	Value
Name	The name of the transformer. This name must be unique.
MIME Type	The MIME type that the transformer supports.
SimpleResult DTD Version	The SimpleResult DTD version, such as 1.0.0 (the default version).
Java Transformer	Specifies a Java class transformer implementation.
Class Name	The name of the class that implements the transformer.
XSL Transformer	Specifies an XSLT style sheet transformer implementation. If you select an XSL transformer, you can do one of the following: Enter the code for the XSL style sheet in the field next to the Style sheet parameter, then click Finish. Using a text editor, open an existing XSL style sheet, copy and paste the lines that you want to use, and then click Finish. Click the Import button to import an existing XSL style sheet.
XSL Stylesheet	The actual XSLT style sheet that implements the transformer. You can cut and paste a transformer from another editing environment into this field.
Java Transformer	Specifies a Java class transformer implementation.
Java Class	The name of the class that implements the transformer.

Figure 8-9 The Create Transformer Page

Description of "Figure 8-9 The Create Transformer Page"

8.4.2 Editing a Transformer

To edit a transformer, select a transformer from the browsing page and then click Edit. The editing page appears, with its fields populated with the values defined for the selected transformer. Clicking Apply saves any changes. Clicking Cancel sets the parameters back to their previous values and returns you to the browsing page.

8.4.3 Deleting a Transformer

To delete a transformer, select a transformer from the browsing page and then click Delete.

8.5 Managing Adapters

Selecting the Adapters tab invokes the browsing page for the adapters (Figure 8-10). This page includes a table which lists the current adapters by their object IDs in the repository, their status as valid adapters (that is, adapaters which are available to master applications) and by the Java class that either implements the adapter, or serves as an entry point to the classes that implement the adapter.

Figure 8-10 Partial View of the Browse Adapters Page

Description of "Figure 8-10 Partial View of the Browse Adapters Page"

You use this page to create, edit, and delete adapters.

8.5.1 Creating an Adapter

To create an adapter, click Create Adapter in the browsing page. The Create Adapter page appears. To create an adapter, you must define the following parameters, which are described in Table 8-4.

Table 8-4 Parameters of the Create Adapter Page

Parameter	Value
Name	The name of the adapter. The name must be unique.
Valid	Specifies whether the adapter is available to the master applications. If selected, the adapter is available. If this option is clear, then the adapter is invalid and therefore unavailable. As a result, all of the master applications that use the adapter are also invalid.
Java Class	The Java class that either implements the adapter or serves as the entry point for the classes that implement the adapter.

After you enter the needed parameters, click Create. The browsing page reappears, displaying the new adapter. Clicking Cancel clears any values entered and returns you to the browsing page.

8.5.2 Editing an Adapter

To edit an adapter, select the adapter from the browsing page and then click Edit. The Edit Adapters page appears, displaying the values for the selected adapter. Click Apply to commit your changes. Clicking Cancel clears any values entered and returns you to the browsing page.

8.5.3 Deleting an Adapter

To delete an adapter from the repository, select the adapter and then click Delete.

8.5.4 Setting Adapter Parameters

The following sections describe the uses and parameters of the OracleAS Wireless adapters.

Section 8.5.4.1, "Setting the Initialization (Init) Parameters for Adapters"
Section 8.5.4.2, "Setting the Input Parameters for Adapters"

8.5.4.1 Setting the Initialization (Init) Parameters for Adapters

When you create a non-HTTP master application, the Init Parameters page of the Master Application Creation Wizard shows the initialization (init) parameters specific to the type of adapter selected for the master application. When OracleAS Wireless first invokes the adapter, it passes the values that you set in the Init Parameters page to the adapter.

8.5.4.1.1 Setting Init Parameters for the SQL Adapter

The SQL adapter retrieves and adapts content from any JDBC-enabled data source for a master application based on the SQL adapter, the Init Parameters panel includes the following parameters, which are described in Table 8-5.

Table 8-5 Init Parameters for the SQL Adapter

Parameter	Value
JDBC Connect String	The JDBC connect string for the database on which to query, as follows: `jdbc:oracle:thin:@host_name:port:SID` Note: Insert all colons (for example, thin:@host).
JDBC Driver	The Java DriverClass name (for example, Oracle thin driver, `Oracle.jdbc.driver.oracle.driver`)
User Name	The name of the database user.
Password	The password of the database user
Type of Statement	The type of SQL statement used by the master application. Allowable values include: QUERY: for a select statement. This type of statement returns a Simple Result document. You can use output filtering with QUERY statements. PLSQL: to use a PL/SQL procedure. This type of statement returns results to a database buffer. CALL: to run a stored procedure (SQL92 syntax only). This returns either a Simple Result or an Adapter Result element.
The Statement	The actual SQL statement that invokes the query, PL/SQL procedure, or stored procedure. Note: The SQL statement should be entered without a semicolon. You can use input variables in the SQL statement. You must indicate a variable in the statement by prefixing the variable with a colon. For example, you can specify an input variable in a PL/SQL statement as follows: `begin mypackage.foo(:expr); end;` Where `:expr` is the name of the variable. You must define the parameter manually in the input panel.
Minimum DB Connection Pool Size	The minimum number of database connections.
Maximum DB Connection Pool Size	The maximum number of database connections.
Increment Size for the Connection Pool	The increment by which the database connection pool increases.
Idle Timeout (In Minutes)	The time (in minutes) of inactivity that OracleAS Wireless allows before automatically logging the user off the system.

8.5.4.1.2 Setting Init Parameters for the Web Integration Adapter

The Web Integration adapter retrieves and adapts Web content. The Web Integration adapter works with Web Interface Definition Language (WIDL) files to map source content to OracleAS Wireless XML. Typically, the source format for the Web Integration adapter is HTML, but developers can also use the adapter to retrieve content in other formats, such as XML.

Table 8-6 describes the initialization (init) parameters for a master application based on the Web Integration adapter.

Table 8-6 Init Parameters of the Web Integration Adapter

Parameter Value

Parameter	Value
WebIntegrationServer	The machine name and listening port of the Web Integration Server. If the Web Integration Server and the OracleAS Wireless server reside on the same machine, use `localhost:port`. This field is required. The server you specify in this field must be running for the Content Manager to return the adapter parameters.
Interface	The WIDL interface name. This interface must be published to the Web Integration Server. You can publish the interface using the Web Integration Developer. You cannot currently use the WIDL_FILE parameter to identify a WIDL service.
WIDL_FILE	Do not enter a value for this parameter.

WebIntegrationServer

The machine name and listening port of the Web Integration Server. If the Web Integration Server and the OracleAS Wireless server reside on the same machine, use localhost:port.

This field is required. The server you specify in this field must be running for the Content Manager to return the adapter parameters.

Interface

The WIDL interface name. This interface must be published to the Web Integration Server. You can publish the interface using the Web Integration Developer. You cannot currently use the WIDL_FILE parameter to identify a WIDL service.

WIDL_FILE

Do not enter a value for this parameter.

8.5.4.1.3 Setting Input Parameters for the Web Integration Adapter

The master application determines the parameters that display in the panel by querying the adapter. Every input parameter defined in the WIDL interface appears in the Inputs panel, including parameters for other WIDL applications within the WIDL interface.

In addition to the custom input parameters that you create, Web Integration applications provide these parameters:

OutputType
PAsection
InputEncoding

The OutputType specifies the type of XML output that the adapter should return. You can specify RawResult, to return content in Adapter Result format, or SimpleResult, to return content in Simple Result format. For returning the raw result format, you must create a result transformer that converts the result into Simple Result for the device transformer. The result transformer should have the same name as the value you use for the PAsection parameter; that is, it should have the same name as the WIDL application.You can use RawResult for chained services.

PAsection is the name of the WIDL application that you want the master application to invoke. A WIDL interface can include more than one WIDL application. OracleAS Wireless lists the WIDL application names in a selection list in the value field.

InputEncoding specifies the encoding used to encode the source document. The source document is the URL that was used to create the WIDL file for this application. The default value of this parameter is UTF-8. If the language of the source document is an Asian language, you can change the default encoding to the appropriate multi-byte encoding according to the IANA standards for the particular Asian language that is used in the source document. The InputEncoding parameter enables you to specify or change the encoding as part of the multi-byte character support.

8.5.4.2 Setting the Input Parameters for Adapters

The Input Parameters page displays the input parameters for the adapter. The OracleAS Wireless Server queries the adapter definition to determine the parameters that appear in this panel. The master application passes the input parameter values to the adapter's invoke method every time the adapter executes.

Some parameters rely on user input for values. The values for other parameters, such as name of the WIDL application in the WIDL interface (PAsection), are set by the master application or application link. PAsection is an internal parameter, not exposed to the end user. In addition to PAsection, OracleAS Wireless provides these input parameters, which are described in Table 8-7.

Table 8-7 Input Parameters for a Non-Http Master Application

Parameter	Value
`PAservicepath`	The relative path to a OracleAS Wireless application, such as `/UsersFolders/joe/myChain`.
`PAdebug`	The debugging option. If set to true (that is, the value is set to 1), then OracleAS Wireless produces verbose output to the log files. For verbose logging, OracleAS Wireless writes the results of adapter invocations to the log file along with notifications and warnings. This enables you to examine application content in its internal, XML format, which can help you to create result transformers and solve application and transformer problems.
`PAsection`	The WIDL adapter uses this value to identify the application that serves as the entry point in the chained application sequence.
`PAuserid`	The user name.
`PApassword`	The user password.
`PAsid`	The OracleAS Wireless session identifier.

Table 8-8 describes the OracleAS Wireless input parameters.

Table 8-8 Input Parameter Attributes

Parameter	Value
Name	The name of the input parameter. The OracleAS Wireless sets the name of the input parameter by querying the adapter definition.
Caption	The caption is the label that OracleAS Wireless uses for the parameter when prompting for user input.
Comment	In the case of master applications based on the Web Integration adapter, OracleAS Wireless automatically populates this field with the name of the WIDL application that uses the parameter. For applications based on other adapters, you can use this column to document the parameter. The comment is only used internally.
User Customizable	Specifies whether the end user can set a value for this parameter using OracleAS Wireless Customization. You can make most input parameters customizable by the user. In particular, you should set this option for parameters that may be difficult for a user to enter from a mobile device. This includes e-mail addresses and personal identification numbers.
Format	This mask sets the expected data entry mode for the user device. For example, if you expect the user to enter numbers for the parameter, you use the format code N. This works only with WML 1.1-compliant devices. The default format is *M (all formats). Other formats include: A, for entry of uppercase letters or punctuation a, for entry of lowercase letters or punctuation N, for entry of numeric characters. X, for entry of uppercase letters. x, for entry of lowercase letters. For a complete list of formats, see the Wireless Application Protocol Wireless Markup Language Specification, Version 1.1.
Mandatory	Select this check box if this parameter must have a value. Remove the selection for optional parameters.
Default Value	For most parameters, this value represents the default value for the parameter. If you specify a default value, OracleAS Wireless does not prompt the user for a value. Default values can be overridden by a value specified by an application link created by the Content Manager or, if the parameter is visible to the user in the OracleAS Wireless Customization Portal. The `PAsection` parameter is used by the Web Integration adapter. For `PAsection`, this value is the name of the WIDL application that the Web application should use. You can select the names from a selection list. If you do not specify a value for `PAsection`, the OracleAS Wireless application includes all WIDL applications in the WIDL interface.

8.5.4.3 Adding a New Input Parameter to the Adapter

From the Input Parameter page click Add Another Row. A blank row appears. Define the name for the input parameter and any other needed parameters in this row, which are described in Table 8-8.

8.5.4.3.1 Setting Input Parameters for the AppsFramework Adapter

The AppsFramework adapter enables the development of enterprise applications on top of Wireless. It provides system-wide standard application look and feel, enhanced application widgets support and data binding to enterprise data.

The AppsFramework adapter includes the input parameter classname which must be the package and class of the implementation of the MobileApplicationHandler interface.

8.5.4.3.2 Modifying the Style, Color, and SDU Information for the Mobile Application Framework Adapter

The Mobile Application Framework adapter uses style and color mappings to provide a uniform look and feel that can be customized across all applications running on the server. In addition, carrier-specific information can be specified to the Mobile Application Framework adapter to optimize the content delivered by the adapter. The StyleColorLoader command-line utility is used to modify the style, color, and SDU size information used by the Mobile Applications Framework adapter.

Downloading the Style/Color/SDU Repository

To download the Style/Color/SDU Repository:

Change directory to ORACLE_HOME/wireless/sample
Enter updateStyleColor.bat -D <filename>, where <filename> is the target file that receives the downloaded XML repository. For a UNIX system, enter updateStyleColor.sh -D <filename>.

Uploading the Style/Color/SDU Repository

To upload the Style/Color/SDU/Repository:

Change directory to ${ORACLE_HOME}/wireless/sample.
Enter updateStyleColor.bat -U <filename>, where <filename> is the file containing the Style/Color/SDU information in the specified XML format that should be uploaded into the database. On a UNIX system, enter updateStyleColor.sh -U <filename>.

Modifying the Style/Color/SDU XML Repository File

To modify the Style/Color/SDU XML repository file:

Download the file.
Modify this file by opening it in any text editor. The XML file contains three top-level elements: <StyleSet>, <ColorSet>, <SDUSize>. After making modifications, you then upload the file back into the repository.

Defining a StyleSet

The <StyleSet> elements help the renderers for a given device render application styles into markup language, as described above. For example, if you want to create a prompt- style "Prompt" and bind the style to the text of the prompt, you create a "Prompt" style in the style repository.

Each <StyleSet> element contains a number of <Style> elements. Each <Style> element contains a name, a font face, font size, font style, and font color. Table 8-9 describes the style element properties.

Table 8-9 Style Element Properties

Property Name	Required?	Multiple?	Description
Name	Yes	No	The name of the Style.
FontFace	Yes	No	The name of the font face of the given style.
FontSize	Yes	No	The font size of the given style.
FontColor	Yes	No	The name of the font color of the given style.
FontStyle	Yes	No	The name of the font style of the given style, (that is, Bold, Italic, Plain).

In addition to the <Style> element, the StyleSet contains elements described in Table 8-10.

Table 8-10 StyleSet Element Properties

Property Name	Required?	Multiple?	Description
Name	Yes	No	The name of the `<StyleSet>`. If a StyleSet is not associated with the device, then the `<StyleSet>` named `Default` is assigned to the device.
Inherits	Yes	No	The parent style sheet from which style definition are inherited.Often, the administrator wants only to change a single style between two devices. In such a case, the administrator defines a single `<StyleSet>`, which has all of the style definitions for the first device. The second device then inherits this `<StyleSet>` and only overwrites the styles that are different between the two `<StyleSet>` elements.
Style	Yes	No	This element defines a style.
Device	Yes	No	Describes the type of devices associated with a style set. The two types of devices supported are Phone and PDA.

By modifying application style definitions in a given <StyleSet>, the system administrator can control how the given application style is rendered on the device to which the style set is bound across the whole system. For example, if a PDA device is bound to the StyleSet Default, then changing the prompt style in the default StyleSet to bold from plain results in all prompts appearing in bold rather than in plain when rendered on client devices in the PDA device grouping.

Defining a ColorSet

The <ColorSet> element helps the renderers for a device render application colors into markup language. For a given device, this application color is mapped to a color code, which can be modified by the system administrator to produce the optimal rendering. For example, if a PDA device is bound to the <ColorSet>, Default, then changing the background color in the default <ColorSet> to grey from white results in the background color for all applications on client devices in the PDA device grouping to be grey rather than white.

A <ColorSet> element consists of multiple <Color> elements. The following table describes the propertis common to each <ColorSet>.

Table 8-11 ColorSet Elements Properties

Property Name	Required?	Multiple?	Description
Name	Yes	No	The name of the `<ColorSet>`.
Inherits	Yes	No	The parent `<ColorSet>` from which color traits are inherited. Often, an administrator wants only to change a single application color between two devices. In this case, the administrator defines a single color set which has all of the color definitions for the first device.This color set is then inherited by the second device, which would only overwrite the colors that are different between the two `ColorSet` elements.
Color	Yes	Yes	This element defines a color.
Device	Yes	No	Describes the type of device associated with the style set. The two types supported devices are PDA and Phone.

A <ColorSet> element consists of multiple <Color> elements. The following table describes the properties common to all <Color> elements.

Table 8-12 ColorSet Color Element Properties

Property Name	Required?	Multiple?	Description
Name	Y	N	The name of the Style.
ColorDesc	Y	N	The 24-bit color code of the given color, for example White = #FFFFFF.

Defining SDUSize Information for a Device

The <SDUSize> element enables the renderers for a given device to render an optimized amount of information on pages. For a given device, the <SDUSize> is the upper limit on the amount of information (in bytes) that the network can carry to this device.

A <SDUSize> element consists of two child elements. The following table lists their properties.

Table 8-13 SDUSize Element Properties

Property Name	Required?	Multiple?	Description
Name	Yes	No	The name of the type of device. The two types of devices supported are Phone and PDA.
Value	Yes	No	The 24-bit color code of the given color, for example White = #FFFFFF.

8.5.4.3.3 Setting Input Parameters for the SQL Adapter

You can configure SQL input parameters in the same way that you configure the Web service parameters. You specify input parameters in the SQL statement you use to implement the service.

8.6 Managing Regions

When you click the Regions tab in the Foundation Manager, the main display of the region modeling tool appears (Figure 8-11).

Figure 8-11 The Main Display of the Region Modeling Tool

Description of "Figure 8-11 The Main Display of the Region Modeling Tool"

The region modeling tool enables administrators of a wireless portals to create custom regions that can be associated with location-based applications.

You create a location dependent application by specifying a region. This region can be a system-defined region (one provided out-of-the-box with OracleAS Wireless) or a custom region, one created with the region modeling tool.

A region is a geographic entity, or location. A region can be small (such as a street address) or large (such as a country). A region can be represented by a point, as is often done for addresses and locations of interest (such as airports and museums), or by a polygon, as is usually done for states and countries. For detailed information about using the region modeling tool, refer to the chapter on location services in the Oracle Application Server Wireless Developer's Guide.

8.7 Managing Digital Rights Policies

A digital rights policy restricts the execution of J2ME applications on mobile devices. Out of the box, OracleAS Wireless provides two types of digital rights management (DRM) policies that can be used to package J2ME applications: Count DRM policy, and Interval DRM policy.

The Count DRM policy restricts the number of times that a downloaded J2ME application can be run on a device. The Interval DRM policy sets the period in which a downloaded J2ME application can be run on a device from the time the user downloads the application. In addition, OracleAS Wireless provides a platform to create a customized digital rights policy.

All digital rights policies created using the Foundation Manager can be selected from the Content Manager when creating an application link based on a J2ME application. For more information, see Section 6.3.4.

Use the Digital Rights Policy subtab to manage the digital rights policies. When you click the Digital Rights Policy subtab, the browsing page for digital rights policies appears (Figure 8-12), displaying a list policies in the repository.

Figure 8-12 The Browsing Page for Digital Rights Policies

Description of "Figure 8-12 The Browsing Page for Digital Rights Policies"

8.7.1 Creating a Digital Rights Policy

OracleAS Wireless provides a two-step wizard which enables you to create a digital rights policy. To access this wizard, click Create in the browsing page.

Step 1: Selecting the Digital Rights Policy Package Type

There are two types of digital rights policy packages: one is a default package provided by OracleAS Wireless; the other is a customized package that you can plug into the OracleAS Wireless platform. If you select this customized package, then you must specify the full class name of the packaging class, which implements the oracle.wireless.me.server.tools.drm.DRMPackager interface.

To create a digital rights policy, click Create. The page for the policy's attributes page appears (Figure 8-13).

Figure 8-13 Entering the Attributes for a Digital Rights Policy

Description of "Figure 8-13 Entering the Attributes for a Digital Rights Policy"

Step 2: Entering the Digital Rights Policy Detail Attributes

If you selected the Default Package, then you must specify the following attributes:

A name for the digital rights policy. This is a required parameter.
A description for this digital rights policy. This is an optional parameter.

Selecting the Usage Policy

To limit the number of times that a user can execute a downloaded J2ME application, define the values for the Usage Time, or Usage Count options.

For the Usage Time option, specify the number of years, months, days, hours or minutes that the user can execute the downloaded application. Define the Usage Count option by specifying the number of times that a user can execute a downloaded J2ME application.

Entering the Initialization Properties

Each time that the user executes an application, a message displays on the user's device informing the user of the remaining number of times (or the remaining amount of time), that the user has to access the application. To create such a message, define the msg.subfix, msg.expire, and msg.prefix parameters. Table 8-14 describes these parameters, which enclose the usage count display presented to the user for each download.

Table 8-14 Initialization Parameters of a Digital Rights Policy

Parameter	Value
msg.subfix	The punctuation and text that follow the usage count data. For example, enter times.
msg.expire	The text telling the user that the application has expired, or is no longer available. For example, enter This application has expired!
msg.prefix field	The text that precedes the user count display. For example, enter This application expires after [times].

Click Create to complete the policy.

Defining a Customized Package

If you selected the Customized Package option in Step 2, then you must define a name for the digital rights policy and optionally enter a description for the policy in the New Digital Rights Policy page (Figure 8-14).

You can also enter an Open Digital Rights Language (ORDL) document, an XML document which expresses the Digital Rights Policy. This ODRL document is consumed by the packaging object which implements oracle.wireless.me.server.tools.drm.DRMPackager.

In addition, you can enter the initialization (init) properties associated with the policy. The init property name and value pairs are passed to Custom Digital Right implementation class. This implementation class uses these value pairs.

Click Finish to complete the policy.

Figure 8-14 Defining a Customized Package

Description of "Figure 8-14 Defining a Customized Package"

8.7.2 Editing a Digital Rights Policy

The Edit button in the digital rights policy browsing page enables you to edit all the parameters of a selected digital rights policy.

To edit a digital rights policy, select the digital rights policy from the browsing page and the click the Edit button. Clicking Finish saves the changes to the policy. Clicking Cancel sets the parameters back to their previous values and returns you to the browsing page.

Refer to Section 8.7.1 for descriptions of the parameters that you can edit.

8.7.3 Deleting a Digital Rights Policy

To delete a digital rights policy from the repository, select a policy from the browsing page and then click Delete.

8.7.4 Enabling or Disabling a Digital Rights Policy

To enable or disable a digital rights policy from the repository, select a policy from the browsing page and then click Enable/Disable.

8.8 Managing API Scan Policies

An API scan policy defines the malicious APIs which can be invoked from a J2ME application that compromise a user's device. The API scan policy definition includes the malicious API package as well as the class and method names. During the certification process, the OracleAS Wireless server references the API scan policy objects when scanning a J2ME application for the APIs defined in the API scan policies. For information on how to scan a J2ME application, refer to Section 6.3.5.1.

You use the API Scan Policy subtab to manage the API scan policies. When you click the API Scan Policy subtab, the API scan policy browsing page appears (Figure 8-15), displaying a list of the API Scan Policies in the repository.

Figure 8-15 The Browsing Page for API Scan Policies

Description of "Figure 8-15 The Browsing Page for API Scan Policies"

8.8.1 Creating an API Scan Policy

The API scan policy creation wizard enables you to create a policy. To access this wizard, click the Create button on the browsing page.

To define a policy, you must provide a name for the policy and then optionally enter a description.

Enter the XML Document which defines the malicious APIs. This XML document is based on the OracleAS Wireless Filter XML Schema. The text area of the Create API Scan page displays a sample API scan document which defines the package, classes, and methods of the API that the OracleAS Wireless server references when scanning the J2ME application.

Click Finish to complete the API scan policy.

8.8.1.1 Editing an API Scan Policy

The Edit button in the API scan policy browsing page enables you to edit the description of a selected API scan policy.

8.8.1.2 Deleting an API Scan Policy

To delete an API scan policy from the repository, select the policy from the browsing page and then click Delete.

8.8.1.3 Enabling or Disabling an API Scan Policy

To enable or disable an API scan policy from the repository, select the policy and then click Enable/Disable.