DB2 Web Service Provider Security

"Guided reading" in this article, we will explain how to enable security for the DB2 Web service Provider application, which includes enabling authentication, setting up authorization, and ensuring that messages are encrypted. We will also explain how WEB service users are mapped to database users.

The Ibm®db2®web service provider (or the Worf--web service Object Runtime Framework) allows us to easily expose database data and stored procedures as WEB services. This requires the user to write an XML file that contains the database operations that make up the Web service transaction. These actions can be SELECT statements, insert/update/delete statements, stored procedures, and XML Extender operations. This article describes how to constrain the user to access these operations that can update or get database data.

What is a Web service?

WEB Services is a message-oriented communication framework designed to be highly interoperable and scalable.

Messages are exchanged in XML format and are described through SOAP (Simple Object Access Protocol). A SOAP message consists of an envelope that includes a header and a body. The header includes some metadata about the message, which can be a transaction ID or encryption key. The subject includes the actual message, which can be an order or an insurance quote.

The actual interface of the Web service provider is described by the Web Service Description Language (Web Services Description language,wsdl). This is very similar to the header file in the C programming language. WSDL tells the user what an operation the Web service provider understands, and what the input and output of the operation are. The WSDL also includes a new type definition that is specific to the WEB service.

Once the WSDL is understood, the user can create XML for the SOAP request message. The user also knows what XML is expected to come from the SOAP response. Typically, there are tools for building SOAP requests and extracting data from SOAP responses. The tools you might use include Websphere®studio and Microsoft®visual Studio. NET. See Resources for an article that explains how to use the DB2 Web service provider with Visual Studio. NET.

Typically, SOAP messages are sent over HTTP, but there may be other kinds of transmissions, such as WebSphere MQ.

WEB services are highly interoperable because of the widespread use of standards such as HTTP and XML. Server-side and client can use different operating systems, application servers, and development tools. Accessing a WEB service does not require client code such as database drivers to be installed.

DB2 Web Service Provider

The DB2 Web service provider is an extension of the Java™ application server (such as WebSphere application Server and Jakarta Tomcat). Web service providers will allow you to write database operations in an XML file and convert those operations into a Web service. An example of this XML file is the DADX (document Access definition extension) file, which looks like this:

Listing 1. A simple DADX file

＜?xml version="1.0"?＞
＜DADX xmlns="http://schemas.ibm.com/db2/dxx/dadx" xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
＜documentation＞List contents of DEPARTMENT table.＜/documentation＞
＜operation name="listDepartments"＞
＜documentation＞Lists each department.＜/documentation＞
＜query＞
＜SQL_query＞SELECT * FROM DEPARTMENT WHERE deptno=:deptno＜/SQL_query＞
＜parameter name="deptno" type="xsd:string" kind="in" /＞
＜/query＞
＜/operation＞
＜/DADX＞

The WEB service provider runtime does the following things at run time:

Create WDSL from DADX file.

Create a browser-based test environment from DADX.

Use the DADX file as an implementation of the WEB service.

Because users only need to write DADX files, the WSDL specification is not required. The WSDL length of a moderately complex DADX may have many pages. The runtime determines the parameters of an SQL operation (such as the deptno in this example) and also analyzes the metadata of the SQL result set to create the correct XML output type.

The user completes the following steps to create an DADX application:

Create a DADX file.

Create and deploy a WEB application.

Access to a browser-based test environment, for example, Http://localhost:9080/services/sample/list.dadx/TEST.

Modify the DADX in the Web application and invoke the test again.

Queries in DADX work as an implementation because the runtime executes the query and formats the result as XML. This means that users do not need to write code in a programming language and understand the programming model of the WEB service engine. If the user himself wants to write a Web service for WebSphere, he will need to write Java code or Enterprise java Bean (EJB) to invoke SQL.

The URLs used to access the test environment include the DADX name (for example, LIST.DADX) and other parts. One part is "services", which is the name or context root of the Web application where DADX resides. Another section (MyDatabase) is a group name. A group is a container for DADX files in a WEB application. Groups share configuration settings with each other, such as database users who connect to the database. In the back, we will see if the metabase user is configured.