5 Consuming Web Services Using the ADF Model Layer

This chapter describes how to create ADF data controls for SOAP and REST web services so that you can better use those services in the user interface.

This chapter includes the following sections:

5.1 About Web Service Data Controls in ADF Applications

Web services allow enterprises to expose business functionality irrespective of the platform or language of the originating application because the business functionality is exposed in such a way that it is abstracted to a message composed of standard XML or JSON constructs that can be recognized and used by other applications.

Web services are modular business services that can be easily integrated and reused, and it is this that makes them ideally suited as components within SOA. JDeveloper helps you to create top-down web services (services created starting from a WSDL), bottom-up web services (created from the underlying implementation such as a Java class or a PL/SQL stored procedure in a database), and services created from existing functionality, such as exposing an application module as a service.

Note:

It is also possible to create a data control based on a connection to a REST web service resource that has been created from an ADF Business Components application module. Such a data control does not require any manual configuration, because the necessary metadata is provided in the REST service's describe endpoint. For more information on creating such data controls, see "Consuming REST Web Services Based on ADF Business Components" in Developing Fusion Web Applications with Oracle Application Development Framework.

Also note that in order to edit a REST data control in JDeveloper, it must be based on a REST connection. If you have created a REST data control from a URL connection in a prior release of JDeveloper, the connection is converted to a REST connection when you migrate the application to the current release.

5.1.1 Web Service Data Control Use Cases and Examples

You can consume web services in web applications, and common reasons for wanting to do so are:

To add functionality which would be time-consuming to develop with the application, but which is readily available as a web service
To access an application that runs on different architecture
To access an application that is owned by another team when their application must be independently installed, upgraded, and maintained, especially when its data is not replicated locally (for example, when other methods of accessing their application cannot be used)

5.1.2 Additional Functionality for Web Service Data Controls in ADF Applications

You may find it helpful to understand other Oracle ADF features before you start working with web service data controls. In addition, it may be helpful to understand support for developing web services in JDeveloper. Following are links to other functionality that may be of interest.

You can design a databound user interface by dragging an item from the Data Controls panel and dropping it on a page as a specific UI component. For more general information on using data controls, see Using ADF Data Controls.
If you are working behind a firewall and you want to use a web service that is outside the firewall, you must configure the web browser and proxy settings in JDeveloper, as described in "Setting Browser Proxy Information" in Developing Fusion Web Applications with Oracle Application Development Framework.
If you are developing the web services that you will later expose through data controls, you can use JDeveloper features to simplify the process. For more information, see "Developing and Securing Web Services" in Developing Applications with Oracle JDeveloper.

The following chapters provide information about specific objects you can use in data controls:

For information about using collections on a data control to create forms, see "Creating a Basic Databound Page" in Developing Fusion Web Applications with Oracle Application Development Framework.
For information about using collections to create tables, see "Creating ADF Databound Tables" in Developing Fusion Web Applications with Oracle Application Development Framework.
For information about using master-detail relationships to create UI components, see "Displaying Master-Detail Data" in Developing Fusion Web Applications with Oracle Application Development Framework.
For information about creating lists, see "Creating Databound Selection Lists and Shuttles" in Developing Fusion Web Applications with Oracle Application Development Framework.
For information about creating graphs, charts, and other visualization UI components, see "Creating Databound Chart and Gauge Components" in Developing Fusion Web Applications with Oracle Application Development Framework.

5.2 Creating Web Service Data Controls

The most common way of using web services in an application developed using Oracle ADF is to create a data control for an external web service. A typical reason for doing this is to add functionality that is readily available as a web service, but which would be time consuming to develop with the application, or to access an application that runs on a different architecture.

Additionally, you can reuse components created by Oracle ADF to make them available as web services for other applications to access.

5.2.1 How to Create a Data Control for a SOAP-based Web Service

JDeveloper allows you to create a data control for an existing web service using just the WSDL for the service. You can browse to a WSDL on the local file system, locate one in a UDDI registry, or enter the WSDL URL directly.

Note:

If you are working behind a firewall and you want to use a web service that is outside the firewall, you must configure the web browser and proxy settings in JDeveloper. For more information, see "Setting Browser Proxy Information" in Developing Fusion Web Applications with Oracle Application Development Framework.

Before you begin:

It may be helpful to have an understanding of how web service data controls are used in ADF applications. For more information, see Creating Web Service Data Controls.

You may also find it helpful to understand additional functionality that can be added using other web services features. For more information, see Additional Functionality for Web Service Data Controls in ADF Applications.

You also need to create an application workspace and a project in that workspace. Depending on how you are organizing your projects, you can use an existing application workspace and project or create new ones. For information on creating an application workspace, see "Creating Applications and Projects" in Developing Applications with Oracle JDeveloper.

To create a data control for a SOAP-based web service:

In the Applications window, right-click the project in which you want to create a web service data control and choose New > From Gallery.
In the New Gallery, expand Business Tier, select Web Services and then Web Service Data Control (SOAP/REST), and click OK.
In the Create Web Service Data Control wizard, on the Data Source page, type a name for the data control, select the SOAP radio button, enter a WSDL URL, and the specify the specific web service to be accessed by the data control.
On the Data Control Operations page, shuttle the operations that you want the data control to support to the Selected panel.

Optionally, select the Include HTTP Header Parameter checkbox. For more information, see How to Include a Header Parameter for a Web Service Data Control.
On the Response Format page, specify the format of the SOAP response.
On the Endpoint Authentication page, specify the authentication details for the endpoint URL, and click Finish.

5.2.2 How to Create a Data Control for a RESTful Web Service

JDeveloper allows you to create a data control for a RESTful web service using a connection to the web service and schema for the methods that you want to invoke.

Before you begin:

It may be helpful to have an understanding of how web service data controls are used in ADF applications. For more information, see About Web Service Data Controls in ADF Applications.

You will need to complete these tasks:

Create an application workspace and a project in that workspace. Depending on how you are organizing your projects, you can use an existing application workspace and project or create new ones. For information on creating an application workspace, see "Creating Applications and Projects" in Developing Applications with Oracle JDeveloper.
If you have any local schema files (XSD or JSON) that you need to include to describe response or payload formats, copy those to the project's resource path as described in What You May Need to Know About Making an XML Schema Available to a REST Data Control.

To create a data control for a RESTful web service:

In the Applications window, right-click the project in which you want to create a web service data control and choose New > From Gallery.
In the New Gallery, expand Business Tier, select Web Services and then Web Service Data Control (SOAP/REST), and click OK.
In the Create Web Service Data Control wizard, on the Data Source page, specify a name for the data control and select the REST radio button.
Select Generic Data Control with manually described features.
In the Connection field, select the REST connection to use.

If you have not established a REST connection, click the Create a new REST connection icon to open the Create REST Connection dialog. In that dialog, enter a name for the connection and a base URI. Do not include any resources or parameters in the URL.

Note:

In the Create REST Connection dialog, you can click Test Connection to verify that you can connect to the URI. However, the URI's server may be configured to not accept requests on the base URI, meaning that the test will fail. Regardless of that fact, you can click OK to create the connection.

If you have such a base URI and would like to make sure that you can connect to the service, you can temporarily add a resource to the URL, test the connection, and then remove the resource before clicking OK.
On the OWSM Policies page, you can optionally set policies for the web service client as required.
On the Resources page, specify a resource for the connection by completing the following sub-steps for each resource:
1. Click the Add icon to add a resource path.
2. Type the name of the resource path inline.
  
  As part of the resource path you can also enter path parameters.
  
  Enter any path parameters in the form ##paramName##. For example, if the web service to be accessed supplies stock quotes, the full URL for the resource for one of the stocks is http://www.example.com/quotes/ACOMPANY, and the path parameter name is ticker, you would enter the following as the resource path:/quotes/##ticker##.
  
  Note:
  
  You can also use a parameter to provide dynamic input for the source path (for example, /##servicename##/##ticker##) where the user would be expected to also provide the service name (such as quote).
  
  If you wish to create any resources with query parameters (i.e. parameters that take the form ?ParamName=ParamValue), you can specify those parameters on the next page of the wizard.
3. Select the appropriate data format (XML or JSON) from the Data Format dropdown list.
4. In the right side of the dialog, with the resource path selected, select one of the checkboxes to specify a REST method for the resource path and then type a name that you can use to identify that method in the Data Controls panel.
Repeat step 7 for each resource you would like to include in the data control.

Figure 5-1 shows the Resources page of the wizard with two resources entered, the second of which includes a path parameter. As shown in the figure, the second resource is selected and a GET method is specified for it.

Figure 5-1 Resources Page of Create Web Service Data Control Wizard
On the Method Details page, select a method and specify a schema file (XSD or JSON) that provides the data format for that method.

If the schema files that you are providing are local, you first need to place them in the project's resource path as described in What You May Need to Know About Making an XML Schema Available to a REST Data Control.

If you do not have a schema file for the data format, you can generate one from a snippet of sample code. To generate the data format from sample code, select the appropriate method in the Resource Methods list, click the Parse from Sample Code radio button and paste a snippet of sample code into the Response Sample text box.

For GET method, the application creates a schema automatically by making a GET call to the specified resource. Therefore, if you do not have a schema for a resource for which you specified the GET method, you can skip providing the schema file in the Method Details page. When you click the Next button, the application creates the schema for the GET method by making a GET call to the resource.

Tip:

You can also use an XSL style sheet to define custom elements based on the response XML to include in the data control. When you use this approach, the schema that you specify in the Response XSD field must be based on the style sheet that you specify in the Response XSL field. For more information, see How to Add Custom Attributes to a RESTful Web Service Data Control.
If the method is a PUT, PATCH or POST method, specify a schema for the request payload in the Payload XSD/JSON field, or click the Parse from Sample Code radio button and paste a snippet of sample code into the Payload Sample text box.
For the selected method, specify any URL parameters and default values.

For parameters that were included in the resource path, the parameter names are included in the URL Parameters list. For these parameters, you need to fill in a default value.

For example, from the sample parameter shown in step 7, ticker would be the parameter name and ACOMPANY could be the default value.

For path parameters of GET methods, it is not necessary to provide a default value if you have provided a response file for the method in step 9.
Optionally, select the Include HTTP Header Parameter checkbox. For more information, see How to Include a Header Parameter for a Web Service Data Control.
Repeat steps 9 through 12 for each method.

Figure 5-2 shows the Method Details page with the getDetails method selected, a response file specified, and default value set for its deptId parameter.

Figure 5-2 Method Details Page of the Create Web Service Data Control Wizard
On the Finish page, review the details of the data control to be generated, and click Finish.

5.2.3 What You May Need to Know About Using Path Parameters in REST Data Controls

When you include path parameters in a REST data control resource, these parameters are issued as part of the HTTP request at runtime. If a value for the path parameter is not provided or the provided value is not found, the service will return a 404 Not Found exception.

When the page is initially rendered at runtime, the parameters are often blank, expecting the user to provide the value for one or more parameters. So the initial request (which is issued when the page is rendered) is sent without parameter values, resulting in the 404 Not Found exception.

For example, say a given page shows a form that accesses a web service that supplies stock quotes, and the URL for the resource is http://www.example.com/quotes/##ticker##, where the path parameter name is ticker. When the user first opens the page, the field provided for input of the ticker symbol is initially blank. So the implicit initial request returns an exception.

To avoid this scenario, you can set a refresh condition on the accessor iterator so that it doesn’t refresh without the input value. In the Applications window, double-click the page definition file of the page that contains the form. In the overview editor for the page definition file, select the accessor iterator. Then, in the Properties window, expand the Advanced section and add an expression like the following in the RefreshCondition field (replacing param-name with the name of the path parameter):

#{bindings.param-name.inputValue ne null}

Note that the default values that you provide on the Method Details page of the Create Web Service Data Control wizard are for design time testing purposes only. When you deploy and run the application, the default values are not included.

Note:

Use RefreshCondition to avoid 404 exception when using REST data controls with path parameters.

5.2.4 How to Include a Header Parameter for a Web Service Data Control

When using a web service data control, you may want to add a custom parameter to the HTTP header when invoking the HTTP request. Such a parameter can be useful for a variety of purposes, including for security or for notifications. For example, you may want to add an enterprise ID to the HTTP header when invoking the request. This enterprise ID in the request allows the web service data control to specify which cloud service the request will be directed to.

To configure the web service data control to use a header parameter, you select Include Http Header Parameter in the Create Web Service Data Control wizard. For SOAP-based web service data controls, this is on the Data Control Operations page. For REST-based web service data controls, it is on the Method Details page.

After creating the data control, you will be able to see the HttpHeader parameter in the Data Controls panel under the Parameters node of the web service data control's methods. In addition, the AdapterDataControl element for the web service data control (in the .dcx file) contains an <httpHeaders paramName="HttpHeader"/> element.

To use the HttpHeader parameter, you will need to create a backing bean in the user interface project for the web service data control. The value for the HttpHeader parameter is provided through the backing bean. The backing bean must have a property of the type Map and the name/value pairs for the HTTP headers should be added to that property. Additionally, the Map must be of type <String, List<String>> or <String,String>, and you should expose the property with getter and setter methods, as shown in the following example.

public class BackingBean {
  private Map<String,Object> httpHeadersMap = new HashMap<String,Object>();
  public BackingBean() {
    List<String> headersList = new ArrayList<String>();
    headersList.add("Oracle");
    httpHeadersMap.put("enterpriseID",headersList);
  }
  public void setHttpHeadersMap(Map<String,Object> httpHeadersMap) {
    this.httpHeadersMap = httpHeadersMap;
  }
  public Map<String,Object> getHttpHeadersMap() {
    return httpHeadersMap;
  }
}

When you drag and drop the operation from the Data Controls panel onto a page as an ADF Parameter Form, remove the HttpHeader from the list of fields. Then, in the Edit Action Binding dialog, under the Parameters section specify the value for HttpHeader parameter by providing an expression that points to the backing bean Map property. Figure 5-3 shows the Edit Action Binding dialog.

Figure 5-3 Edit Action Binding Dialog

This image is described in the surrounding text

5.2.5 How to Access Response HTTP Headers for a RESTful Web Service

When you access the Response HTTP Header parameter, you need to access the action binding in a bean class, from where the value is provided. If the action binding is not executed, then execute the action binding to get the responseHTTPHeader parameter. A sample code for action binding to get the responseHTTPHeader parameter is given below.

Map responseHeaders; 
public Map getResponseHeaders() { 
        findResponseHeaders();
        return responseHeaders; 
} 
private void findResponseHeaders() 
{ 
        BindingContainer bindings = BindingContext.getCurrent().getCurrentBindingsEntry(); 
        JUCtrlActionBinding operationBinding = (JUCtrlActionBinding)bindings.getOperationBinding("testrest");
        RestURLDataControl dc = (RestURLDataControl)operationBinding.getDataControl().getAdaptedDC(); 
        responseHeaders = dc.getResponseHTTPHeaders(); 
}

It may be helpful to have a general understanding of data controls for RESTful web services. For more information, see How to Create a Data Control for a RESTful Web Service.

You may also find it helpful to understand how to use ADF data controls. For more information, see Using ADF Data Controls.

5.2.6 How to Refresh a SOAP Web Service Data Control

After updating a SOAP-based web service data control, you might find that a web service operation has changed in its method signature, return type, or structure. When this happens, you can update the data control without having to re-create it.

Before you begin:

It may be helpful to have an understanding of how web service data controls are used in ADF applications. For more information, see Creating Web Service Data Controls.

To refresh an operation in a SOAP-based web service data control:

In the Applications window, select the DataControls.dcx file for the web service data control.
In the Structure window, right-click the desired web service operation and choose Update.

JDeveloper queries the web service and updates the web service data control to reflect the current state of the selected operation.

5.2.7 What You May Need to Know About Primary Keys in SOAP Web Service Data Controls

When you create a data control on a SOAP-based web service, the data control supports primary key operations on any exposed collection.

If the web service definition references a schema that defines an element or attribute as type xsd:ID, the data control will expose the attribute as a key attribute and make the setCurrentRowWithKey and setCurrentRowWithKeyValue data control operations available for the collection.

For example, your schema could set the deptno attribute as the primary key using the <xsd:attribute> element as shown below:

<xsd:attribute name="deptno" type="xsd:ID" use="required"/>

Or the schema could set the deptno attribute as the primary key using the <xsd:element> element as shown below:

xsd:element name="deptno" type="xsd:ID"/>

Note:

The XSD entries shown above are generated at runtime if you have created the web service from a Java class and added the JAXB @XmlID annotation and either @XmlAttribute(required=true) or @XmlElement(required=true) to the field or the getter method representing the key.

If no ID is defined for a collection in one of the above ways, the data control creates a hidden attribute for the collection that serves as an index-based primary key. You can then use the setCurrentRowWithKey or setCurrentRowWithKeyValue data control operation to pass the index of the row.

Note:

If you do not see the setCurrentRowWithKey or setCurrentRowWithKeyValue operations for a collection in the Data Controls panel, you may need to manually update the DataControls.dcx file to have those operations exposed. To do so, open the Source view of the DataControls.dcx and change the value of the service's ensureKeyAttribute property to true. Then, in the Data Controls panel, click the Refresh icon to refresh the list of operations.

5.2.8 How to Add Custom Attributes to a RESTful Web Service Data Control

Before you create a data control based on a RESTful web service, you can create an XSL style sheet to transform the content of the REST service into a custom XML format to incorporate into the data control. For example, you can create elements that are calculated from other elements returned by the service and have those elements exposed in the data control as attributes on which you can base UI components.

The following example shows a style sheet that defines NAME and DEPTID elements to be derived directly from the response XML. In addition, the style sheet defines the CUSTOMNAME and UNIQUEID elements, the values of which are calculated from the NAME and DEPTID elements. A data control created on the basis of this style sheet would expose all four of these elements as attributes.

<?xml version="1.0" encoding="windows-1252" ?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="DEPARTMENTS">
    <DEPARTMENTS>
      <xsl:for-each select="DEPT">
        <DEPT>
          <NAME><xsl:value-of select="NAME"/></NAME>
          <DEPTID><xsl:value-of select="DEPTID"/></DEPTID>
          <CUSTOMNAME><xsl:value-of select="concat('CUST_',NAME)"/></CUSTOMNAME>
          <UNIQUEID><xsl:value-of select="DEPTID * 2"/></UNIQUEID>
        </DEPT>
      </xsl:for-each>
    </DEPARTMENTS>
  </xsl:template>
</xsl:stylesheet>

After you create the style sheet, you need to create an XML schema that incorporates the custom elements. One way to simplify this process is to create an XML file based on the response format that includes the custom elements and then use JDeveloper's XML tools to generate a schema based on that XML file.

The following example shows an XML file that contains both the base and custom elements that are defined in the style sheet shown in the previous example .

<?xml version="1.0" encoding="UTF-8"?>
    <DEPARTMENTS>
      <DEPT>
        <NAME>Marketing</NAME>
        <DEPTID>20</DEPTID>
        <CUSTOMNAME>CUST_Marketing</CUSTOMNAME>
        <UNIQUEID>40</UNIQUEID>
      </DEPT>
      <DEPT>
        <NAME>Marketing</NAME>
        <DEPTID>20</DEPTID>
        <CUSTOMNAME>CUST_Marketing</CUSTOMNAME>
        <UNIQUEID>40</UNIQUEID>
      </DEPT>
    </DEPARTMENTS>

The following example shows the schema based on the modified XML response.

<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.example.org"
            targetNamespace="http://www.example.org" elementFormDefault="qualified">
  <xsd:element name="DEPARTMENTS">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="DEPT" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="NAME" type="xsd:string"/>
              <xsd:element name="DEPTID" type="xsd:integer"/>
              <xsd:element name="CUSTOMNAME" type="xsd:string"/>
              <xsd:element name="UNIQUEID" type="xsd:integer"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Before you begin:

It may be helpful to have an understanding of how web service data controls are used in ADF applications. For more information, see Creating Web Service Data Controls.

To add custom attributes to a REST data control:

Create an XSL style sheet based on the structure of the data returned by the web service and including any custom elements that you want to incorporate.
Based on the format for the method's response XML, create an XML document that also includes the custom elements.

Note:

If a resource can nest multiple resources of a given type, make sure that the XML file includes two or more of those nested resources so that the schema generated in the next step reflects the one-to-many cardinality.
Create an XML schema based on the XML document created in the previous step.

You can do this in JDeveloper by opening the New Gallery, and selecting General > XML > XML Schema from XML Document.
Create a data control as described in How to Create a Data Control for a RESTful Web Service.

In step 9 of the procedure, specify both the Response XSL (the XSL style sheet you have created) and the Response XSD (the XML schema you have created).

5.2.9 What You May Need to Know About Web Service Data Controls

As with other kinds of data controls, you can design a databound user interface by dragging an item from the Data Controls panel and dropping it on a page as a specific UI component. For more information, see How to Use the Data Controls Panel.

In the Data Controls panel, each data control object is represented by an icon. Table 5-1 describes what each icon represents, where it appears in the Data Controls panel hierarchy, and what components it can be used to create.

Table 5-1 Data Controls Panel Icons and Object Hierarchy for Web Services

Name	Description	Used to Create...
Data Control	Represents a data control. You cannot use the data control itself to create UI components, but you can use any of the child objects listed under it. Typically, there is one data control for each web service.	Serves as a container for other objects and is not used to create anything.
Collection	Represents a data collection returned by an operation on the service. Collections also appear as children under method returns, other collections, or structured attributes. The children under a collection may be attributes, other collections, custom methods, and built-in operations that can be performed on the collection.	Forms, tables, graphs, trees, range navigation components, and master-detail components. For more information, see "Creating a Basic Databound Page," "Creating ADF Databound Tables," "Displaying Master-Detail Data," and "Creating Databound Chart and Gauge Components" in Developing Fusion Web Applications with Oracle Application Development Framework.
Attribute	Represents a discrete data element in an object (for example, an attribute in a row). Attributes appear as children under the collections or method returns to which they belong.	Label, text field, date, list of values, and selection list components. For more information, see "Creating Text Fields Using Data Control Attributes" in Developing Fusion Web Applications with Oracle Application Development Framework.
Structured Attribute	Represents a returned object that is a complex type but not a collection. For example, a structured attribute might represent a single user assigned to the current service request. Note: If you specify a HTTP payload method, the Web Services Data Control generates a schema for specified operations (GET, POST, PUT, or DELETE) and displays the input parameters for each operation separately in the Data Controls panel. While designing a page, you can use these input parameters for the operations and can drop on a page as an editable form.	Label, text field, date, list of values, and selection list components. For more information, see "Creating Text Fields Using Data Control Attributes" and "Creating Databound Selection Lists and Shuttles" in Developing Fusion Web Applications with Oracle Application Development Framework.
Method	Represents an operation in the data control or one of its exposed structures that may accept parameters, perform some business logic and optionally return single value, a structure or a collection of those. Note: When you specify a HTTP payload method, the Web Services Data Control generates a schema and displays the specified operations (GET, POST, PUT, or DELETE) in the Data Controls panel. These payload operations are represented as Method. If a Method accepts arguments, those arguments appear in a Parameters node as parameters, nested inside the method's node. While designing a page, you can use these payload operation methods on a form as a command button or link. When you drop an operation on a form, the operation takes the corresponding input parameters that is already dropped as input. You can then bind the form to this button.	Command components. For methods that accept parameters: command components and parameterized forms. For more information, see "Using Command Components to Invoke Functionality in the View Layer"
Method Return	Represents an object that is returned by a web service method. The returned object can be a single value or a collection. A method return appears as a child under the method that returns it. The objects that appear as children under a method return can be attributes of the collection, other methods that perform actions related to the parent collection, and operations that can be performed on the parent collection. When a single-value method return is dropped, the method is not invoked automatically by the framework. You should either drop the corresponding method as a button to invoke the method, or if working with task flows you can create a method activity for it. For more information about executables, see "Executable Binding Objects Defined in the Page Definition File" in Developing Fusion Web Applications with Oracle Application Development Framework.	The same components as for collections and attributes and for query forms. For more information on query forms, see "Creating ADF Databound Search Forms" in Developing Fusion Web Applications with Oracle Application Development Framework.
Operation	Represents a built-in data control operation that performs actions on the parent object. Data control operations are located in an Operations node under collections. If an operation requires one or more parameters, they are listed in a Parameters node under the operation. The following operations for navigation and setting the current row are supported: `First`, `Last`, `Next`, `Previous`, `setCurrentRowWithKey`, and `SetCurrentRowWithKeyValue`. `Execute` is supported for refreshing queries. `Create` and `Delete` are available as applicable, depending on the web service operation. Because the web service data controls are not transactional, `Commit` and `Rollback` are not supported.	UI command components, such as buttons, links, and menus. For more information, see "Creating Command Components Using Data Control Operations" and "Creating an Input Form" in Developing Fusion Web Applications with Oracle Application Development Framework.
Parameter	Represents a parameter value that is declared by the method or operation under which it appears. Parameters appear in the Parameters node under a method or operation. Array and structured parameters are exposed as updatable structured attributes and collections under the data control, which can be dropped as an ADF form or an updatable table on the UI. You can use the UI to build a parameter that is an array or a complex object (not a standard Java type).	Label, text, and selection list components.

5.2.10 What You May Need to Know About Making a Schema File Available to a REST Data Control

Typically, when you include a JSON or XML schema as part of a REST data control, the data control definition stores the reference as an absolute path, which works well if the file that you specify is a network resource. If the schema file that you specify is a local resource, you can place it in your project's resource path so that the file is packaged with your application and the reference to it is stored as a relative path.

If you provide a reference to a local copy of a schema file that is not in the project's resource path, the reference to the resource will be stored as an absolute path. If you subsequently run the application on a local instance of the application server, the schema file will be available to your application. However, if you deploy the application to a remote server, the application will not be able to access the file.

In order to make sure a local copy of the schema file is available to your application when deployed to a remote server instance, you must manually copy the file into the project's resource path before creating the data control.

You can identify the project's resource path in the Project Properties dialog. Expand the Project Source Paths node (in the Project Properties dialog) and select the Resources node, as shown in Figure 5-4. The folders listed in the Resources field are the project's resource path.

Figure 5-4 Project Resource Path

5.2.11 What You May Need to Know About Using the PATCH Method With REST Data Controls

The native Java HttpURLConnection handler does not support the PATCH request. Also if you have overridden the default http handler for Weblogic Server, this will cause PATCH to fail. Even though the PATCH method is supported by the REST data control, the underlying HttpURLConnection must support it at runtime.

To ensure that PATCH functions properly, set the following system property for Weblogic Server and include related jars:

java.protocol.handler.pkgs=weblogic.net

For running a project from JDeveloper, you can set this property at the project level in the launch settings of the Edit Run Configuration dialog. Select the appropriate project, and choose Project Properties from the Application menu. Then in the Project Properties dialog, click Run/Debug, select the appropriate run configuration and click Edit.

5.3 Configuring Security for Web Service Data Controls

Web services allow applications to exchange data and information through defined application programming interfaces. SSL (Secure Sockets Layer) provides secure data transfer over unreliable networks, but SSL only works point to point. Once the data reaches the other end, the SSL security is removed and the data becomes accessible in its raw format. A complex web service transaction can have data in multiple messages being sent to different systems, and SSL cannot provide the end-to-end security that would keep the data invulnerable to eavesdropping.

Any form of security for web services has to address the following issues:

The authenticity and integrity of data
Data privacy and confidentiality
Authentication and authorization
Non-repudiation
Denial of service attacks

Throughout this section the "client" is the web service data control, which sends SOAP or REST messages to a deployed web service. The deployed web service may be:

A web service running on Oracle WebLogic Server
A web service running anywhere in the world that is accessible through the Internet

5.3.1 Oracle WSM Policy Framework

You can use Oracle Web Services Manager (WSM) policy framework to manage and secure web services consistently across your organization. The policy framework is built using the WS-Policy standard, which unifies multiple technologies to make secure web services interoperable between systems and platforms.

Among others, the Oracle WSM Policy Framework addresses the following aspects of web services security issues:

Authentication and authorization

The identity of the sender of the data is verified, and the security system ensures that the sender has privileges to perform the data transaction.

The type of authentication can be a basic username/password pair transmitted in plain text, or trusted X509 certificate chains. SAML assertion tokens can also be used to allow the client to authenticate against the service, or allow it to participate in a federated SSO environment, where authenticated details are shared between domains in a vendor-independent manner.
Data authenticity, integrity, and non-repudiation

XML digital signatures, which use industry-standard messages, digest algorithms to digitally sign the SOAP message.
Data privacy

XML encryption that uses industry-standard encryption algorithms to encrypt the message.
Denial of service attacks

Defines XML structures to time-stamp the SOAP message. The server uses the time stamp to invalidate the SOAP message after a defined interval.

For more information on web service security, see Securing Web Services and Managing Policies with Oracle Web Services Manager

5.3.2 Using Key Stores

A web service can be configured for message-level security using key stores. For more information about creating and using key stores for message protection, see "Configuring Message Protection" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

5.3.3 How to Define SOAP Web Service Data Control Security

After you create a SOAP-based web service data control in a JDeveloper project, you can define security for the data control using the Edit Data Control Policies dialog.

Before you begin:

It may be helpful to have an understanding of how security is used in web service data controls. For more information, see Securing Web Service Data Controls.

To define security for a SOAP web service data control:

In the Applications window, select the web service data control DataControls.dcx file.
In the Structure window, right-click the web service data control and choose Define Web Service Security.

JDeveloper displays the Edit Data Control Policies dialog, which shows the Policy Store location.

Note:

If you want to use an alternative policy store, you must first specify it in the WS Policy Store page of the Preferences dialog. To do so, from the main menu, choose Tools > Preferences and select the WS Policy Store page.
From the Ports dropdown list, select the port to which you want then specified policies applied.
From the MTOM dropdown list, select the MTOM (message transmission optimization mechanism) policy you want to use. If you leave this field blank, no MTOM policy is used.
From the Reliability dropdown list, select the reliability policy you want to use. If you leave this field blank, no reliability policy is used.
From the Addressing dropdown list, select the addressing policy you want to use. If you leave this field blank, no addressing policy is used.
In the Security list, you can optionally specify additional security policies to apply. To add a policy, select its checkbox.
In the WS Config list, you can optionally specify additional web service configuration policies to apply. To add a policy, select its checkbox.

For more information on the configuration policies, see "Configuration Policies" in Securing Web Services and Managing Policies with Oracle Web Services Manager.
In the Management list, you can optionally specify additional management policies to apply. To add a policy, select its checkbox.
If necessary, you can also remove policies from the Security list and the Management lists by deselecting their corresponding checkboxes.
You can optionally override properties for the policies in the Security list and the Management list by clicking Override Properties.
Click OK.

For more information about predefined policies and configuring policies and their properties, see "Configuration Policies" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

5.3.4 How to Define RESTful Web Service Data Control Security

After you create a data control for RESTful web services in a JDeveloper project, you can define security for the data control using the Edit Data Control Policies dialog.

Before you begin:

It may be helpful to have an understanding of how security is used in web service data controls. For more information, see Securing Web Service Data Controls.

To define security for a RESTful web service data control:

In the Applications window, select the web service data control DataControls.dcx file.
In the Structure window, right-click the web service data control and choose Define REST Security.

JDeveloper displays the Edit Data Control Policies dialog, which shows the Policy Store default location.

Note:

If you want to use an alternative policy store, you must first specify it in the WS Policy Store page of the Preferences dialog. To do so, from the main menu, choose Tools > Preferences and select the WS Policy Store page.
In the Security list, you can optionally specify additional security policies to apply. To add a policy, select its checkbox.
In the WS Config list, you can optionally specify additional web service configuration policies to apply. To add a policy, select its checkbox.

For more information on the configuration policies, see "Configuration Policies" in Securing Web Services and Managing Policies with Oracle Web Services Manager.
In the Management list, you can optionally specify additional management policies to apply. To add a policy, select its checkbox.
If necessary, you can also remove policies from the Security list and the Management lists by deselecting their corresponding checkboxes.
You can optionally override properties for the policies in the Security list and the Management list by clicking Override Properties.
Click OK.