5 Exposing 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 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.

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 Chapter 2, "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 Section 5.2, "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 Section 5.1.2, "Additional Functionality for Web Service Data Controls in ADF Applications."

You will need to complete this task:


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:

  1. In the Applications window, right-click the project in which you want to create a web service data control and choose New > From Gallery.

  2. In the New Gallery, expand Business Tier, select Web Services and then Web Service Data Control (SOAP/REST), and click OK.

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

  4. 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 Section 5.2.3, "How to Include a Header Parameter for a Web Service Data Control."

  5. On the Response Format page, specify the format of the SOAP response.

  6. 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 REST 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 Section 5.1, "About Web Service Data Controls in ADF Applications."

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

You will need to complete these tasks:

To create a data control for a RESTful web service:

  1. In the Applications window, right-click the project in which you want to create a web service data control and choose New > From Gallery.

  2. In the New Gallery, expand Business Tier, select Web Services and then Web Service Data Control (SOAP/REST), and click OK.

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

  4. In the Connection field, select the URL connection to use.

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

    Note:

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

    If you have such a base URL 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.

  5. On the Resources page, specify a resource for the connection by completing the following sub-steps for each resource:

    1. Click the Add button 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. In the right side of the dialog, 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.

  6. Repeat step 5 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

    This image is described in the surrounding text
  7. On the Method Details page, select a method and specify an XSD that provides the response format for that method.

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

    If you do not have a schema for the response format, you can create one yourself by recreating the XML for the resource based on its documentation and then creating an XSD from that XML file. In JDeveloper, you can generate an XSD file from an XML document by choosing File > New > From Gallery > XML > XML Schema from XML Document.

    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 Section 5.2.7, "How to Add Custom Attributes to a REST Web Service Data Control."

  8. If the method is a PUT or POST method, specify a schema for the request payload in the Payload XSD field.

  9. 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 5, 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 XSD for the method in step 7.

  10. Optionally, select the Include HTTP Header Parameter checkbox. For more information, see Section 5.2.3, "How to Include a Header Parameter for a Web Service Data Control."

  11. Repeat steps 7 through 10 for each method.

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

    Figure 5-2 Method Details Page of the Create Web Service Data Control Wizard

    This image is described in the surrounding text
  12. On the Finish page, review the details of the data control to be generated, and click Finish.

5.2.3 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 Example 5-1.

Example 5-1 Backing Bean to Support Http Header Parameters in a Web Service Data Control

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.

5.2.4 How to Adjust the Endpoint for a SOAP Web Service Data Control

After developing a web service data control, you can modify the endpoint. This is useful, for example, when you migrate the application from a test environment to production.

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 Section 5.2, "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 Section 5.1.2, "Additional Functionality for Web Service Data Controls in ADF Applications."

To change the endpoint for a web service data control:

  1. In the Applications window, select the DataControls.dcx file for the web service data control.

  2. In the Structure window, right-click the web service data control and choose Edit Web Service Connection.

  3. In the Edit Web Service Connection dialog, make the necessary changes to the endpoint URL and port name.

  4. Click OK.

5.2.5 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 Section 5.2, "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 Section 5.1.2, "Additional Functionality for Web Service Data Controls in ADF Applications."

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

  1. In the Applications window, select the DataControls.dcx file for the web service data control.

  2. 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.6 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.7 How to Add Custom Attributes to a REST 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.

Example 5-2 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.

Example 5-2 XSL Style Sheet for Customizing Format of a REST Response

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

Example 5-3 shows an XML file that contains both the base and custom elements that are defined in the style sheet shown in Example 5-2.

Example 5-3 XML Response That Is Modified with Custom Elements

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

Example 5-4 shows the schema based on the modified XML response.

Example 5-4 XML Schema File Containing Custom Elements

<?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 Section 5.2, "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 Section 5.1.2, "Additional Functionality for Web Service Data Controls in ADF Applications."

To add custom attributes to a REST data control:

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

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

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

  4. Create a data control as described in Section 5.2.2, "How to Create a Data Control for a RESTful Web Service."

    In step 7 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.8 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 Section 2.3.1, "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

Icon Name Description Used to Create...

This image is described in the surrounding text

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.

This image is described in the surrounding text

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.

This image is described in the surrounding text

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.

This image is described in the surrounding text

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.

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.

This image is described in the surrounding text

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.

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"

This image is described in the surrounding text

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.

This image is described in the surrounding text

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.

This image is described in the surrounding text

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.9 What You May Need to Know About Making an XML Schema Available to a REST Data Control

Typically, when you include an 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 XSD that you specify is a network resource. If the XSD that you specify is a local resource, you can place the XSD in your project's resource path so that the XSD 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 an XSD file that is not in the project's resource path, the reference to the resource will be stored as an absolute path. If you then run the application on a local instance of the application server, the XSD 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 XSD.

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

You can identify the project's resource path in the Project Properties dialog.

To identify the resource path for a project:

  1. Right-click the project's node and choose Project Properties.

  2. In the Project Properties dialog, expand the Project Source Paths node and select the Resources node, as shown in Figure 5-3.

    The folders listed in the Resources field are the project's resource path.

Figure 5-3 Project Resource Path

This image is described in the surrounding text

5.3 Securing 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 Section 5.3, "Securing 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 Section 5.1.2, "Additional Functionality for Web Service Data Controls in ADF Applications."

To define security for a SOAP web service data control:

  1. In the Applications window, select the web service data control DataControls.dcx file.

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

  3. From the Ports dropdown list, select the port to which you want then specified policies applied.

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

  5. From the Reliability dropdown list, select the reliability policy you want to use. If you leave this field blank, no reliability policy is used.

  6. From the Addressing dropdown list, select the addressing policy you want to use. If you leave this field blank, no addressing policy is used.

  7. In the Security list, you can optionally specify additional security policies to apply. To add a policy, select its checkbox.

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

  9. In the Management list, you can optionally specify additional management policies to apply. To add a policy, select its checkbox.

  10. If necessary, you can also remove policies from the Security list and the Management lists by deselecting their corresponding checkboxes.

  11. You can optionally override properties for the policies in the Security list and the Management list by clicking Override Properties.

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