Implementing Web Services

Web services enable applications to interact with one another over the Web in a platform-neutral, language independent environment. In a typical Web services scenario, a business application sends a request to a service at a given URL by using the protocol over HTTP. The service receives the request, processes it, and returns a response. You can incorporate calls with external Web services in applications developed in Application Builder.

Web services are typically based on Simple Object Access Protocol (SOAP) or Representational State Transfer (REST) architectures. SOAP is a World Wide Web Consortium (W3C) standard protocol for sending and receiving requests and responses across the Internet. SOAP messages can be sent back and forth between a service provider and a service user in SOAP envelopes. RESTful Web services are resource oriented. The scope of the Web service is found in the URI and the method of the service is described by the HTTP method that is used such as GET, POST, PUT, HEAD, and DELETE.

SOAP offers two primary advantages:

• SOAP is based on XML, and therefore easy to use.
• SOAP messages are not blocked by firewalls because this protocol uses simple transport protocols, such as HTTP.
  
  
  REST offers similar advantages:
• REST messages are also not blocked by firewalls because this protocol uses the HTTP protocol.
• REST requests do not require the overhead of XML and SOAP envelopes and inputs are typically provided in the URI.

Topics:

• Understanding Web Service References
• Working with SSL Enabled Web Services
• Creating a Web Service Reference Based on a WSDL
• Creating a Web Service Reference Manually
• Creating a RESTful Web Service Reference
• Using the Web Service Reference Repository
• Testing a Web Service Reference Created from a WSDL
• Testing a Web Service Reference Created Manually
• Testing a REST Web Service Reference
• Creating an Input Form and Report on a Web Service
• Creating a Form on a Web Service
• Invoking a Web Service as a Process
• Editing a Web Service Process
• Viewing a Web Service Reference History
• Exposing a Report Region as a RESTful Web Service

Using the Native Java Interface

Oracle Database 10g introduces the native Java interface--new features for calls to server-side Java code. It is a simplified application integration: client-side (and middle-tier) Java applications can directly invoke Java in database without the need for defining a PL/SQL wrapper. Uses server-side Java class reflection capability.

In previous releases, calling Java stored procedures and functions from a database client required JDBC calls to associated PL/SQL wrappers. Each wrapper had to be manually published with a SQL signature and a Java implementation. This had the following disadvantages:

• The signatures permitted only Java types that had direct SQL equivalents.
• Exceptions issued in Java were not properly returned.

The JPublisher -java option provides functionality to avoid these disadvantages. To remedy the deficiencies of JDBC calls to associated PL/SQL wrappers, the -java option makes convenient use of an API for direct invocation of static Java methods. This functionality is also useful for Web services.

The functionality of the -java option mirrors that of the -sql option, creating a client-side Java stub class to access a server-side Java class, as opposed to creating a client-side Java class to access a server-side SQL object or PL/SQL package. The client-side stub class uses JPublisher code that mirrors the server-side class and includes the following features:

• Methods corresponding to the public static methods of the server class
• Two constructors: one that takes a JDBC connection and one that takes the JPublisher default connection context instance

At runtime, the stub class is instantiated with a JDBC connection. Calls to its methods result in calls to the corresponding methods of the server-side class. Any Java types used in these published methods must be primitive or serializable.

As an example, assume you want to call the following method in the server:

public String oracle.sqlj.checker.JdbcVersion.to_string();

Use the following -java setting:

-java=oracle.sqlj.checker.JdbcVersion

Web Service Data Sources (Virtual Table Support)

To access data (returned from single or multiple Web service invocations) through a database table, create a virtual table through a Web service data source. This table function allows you to query a set of returned rows as though it were a table.

The client invokes a Web service and the results are stored in a virtual table in the database. You can pass result sets from function to function, allowing you to set up a sequence of transformation without a table holding intermediate results. To reduce memory usage, you can return the result set rows a few at a time within a function.

By using Web services with the table function, you can manipulate a range of input values (from single or multiple Web services) as a real table. In the following example, the inner SELECT creates rows whose columns are used as arguments for invoking the CALL_WS Web service call-out. The table expression could be used in other SQL queries, for constructing views, and so on.

SELECT <some-columns> 
FROM
  TABLE(WS_TABFUN(CURSOR(SELECT s FROM <some_table>))),
WHERE...