Skip to main content

skip to main content

developerWorks  >  Information Management  >

DB2 Web service engines on Linux with Kylix 3: Part 1

developerWorks
Document options

Document options requiring JavaScript are not displayed

Sample code


Rate this page

Help us improve this content


Level: Intermediate

Bob Swart (drbob@chello.nl), Author, Trainer, Consultant, and Webmaster, Bob Swart Training and Consultancy

24 Jun 2004

This article demonstrates how to build a SOAP Web service engine with Kylix 3 on Linux, exposing the data from DB2 UDB database tables to the outside world.

Introduction

Linux is especially renowned for its (Web) server capabilities. In my last article, DB2 Web Server applications on Linux with Kylix 3 and WebSnap, I showed how to build a Web server application using Borland® Kylix™ 3, exposing the IBM® DB2® Universal Database™ (UDB) SAMPLE database on the Web. Clients can connect to this Web application using a regular Web browser.

This time, however, I want to take a slightly different approach by focusing on distributed applications. In this two-part article, I will start by building the server-side "engine" on Linux, exposing the data from the DB2 UDB SAMPLE database, but without the presentation layer. Next time, I'll build the user interface for this presentation layer, which can be on either Linux or Windows.



Back to top


Considering distributed applications

The objective of this article is to demonstrate how to build a SOAP Web service engine with Kylix 3 on Linux, exposing the data from DB2 UDB database tables to the outside world. This actually results in a 3-tier application, where the DB2 UDB database is the first tier (the data layer), the Kylix 3 Web service engine is the second tier (the middleware layer), and next time, you'll write the third tier (the actual presentation layer). The focus of this article is on the middleware layer, connecting to the data layer.

There are several reasons why you would want to turn a regular database application into a distributed application. One of the important reasons is security: separating the data access layer from the presentation layer, you are able to shield the database from the end users (and the potential hackers who are interested in breaking into your database). Another reason to split an application in multiple tiers is performance: a dedicated database server can be used next to a dedicated Web server, and both can be configured for optimal performance. A third important benefit has to do with the fact that the middle tier (which contains the so-called business rules) will run on only one (or a few) servers, so it's relatively easy to update the business rules (especially compared to regular client/server applications, where a change in business rule may mean the modification and redeployment of the client software on all client machines).

In a multi-tier application architecture, the client is often referred to as a thin client, since it is independent of the database deployment details (as you'll see in my next article), since it only needs to connect to the middleware tier.



Back to top


Using Kylix 3: DataSnap and SOAP

Borland offers an application framework called DataSnap to build distributed applications on Windows and Linux. It supports a binary or ASCII message format, DCOM, TCP/IP sockets, and HTTP transport protocols on Windows, as well as SOAP on both Windows and Linux. For Kylix 3, this means you will build a SOAP Web service.

For the example project, you need Kylix 3 as well as IBM DB2 UDB v8.1 installed on a distribution of Linux. I'm using Red Hat 7.2, which works best for my needs. Note that you can download the trial edition of Kylix 3 Enterprise from the Borland Web site.

You may also want to install the Apache Web server, but as I showed you last time, this is not absolutely required for your development machine. Kylix 3 includes its own means to allow you to test and debug your Web applications (without Apache).



Back to top


Building the SOAP Web service

The middleware application server can be implemented by building a SOAP DataSnap Server in Kylix 3 Enterprise. Start Kylix 3 Enterprise, and close the default project (which is a desktop project by default).

Do File | New -Other and go to the Web Services tab of the Object Repository (as shown in Figure 1), where you'll find four possible options: SOAP Server Application, SOAP Server Data Module, SOAP Server Interface, and WSDL Importer.


Figure 1. Kylix 3 Object Repository - WebServices
Figure 1. Kylix 3 Object Repository - WebServices

You need the first two, starting with the SOAP Server Application. So, double-click on the SOAP Server Application icon, which results in the New SOAP Server Application dialog, as shown in Figure 2.


Figure 2. New SOAP Server Application
Figure 2. New SOAP Server Application

For testing and debugging purposes, you can use the Web App Debugger executable target. This one does not require a Web server like Apache to be available (as demonstrated last time in the WebSnap article). For real-world deployment, however, you should select either a CGI stand-alone executable or an Apache shared module.

If you cannot make up your mind, you can always modify the project later, or even use a project group with multiple targets in Kylix, all sharing the same Web module and data modules.

Anyway, make a selection and click on the OK button to allow Kylix 3 to create a new SOAP Server Application for you. Kylix 3 will automatically generate a new Web module with three special components: a THTTPSoapDispatcher, a THTTPSoapPascalInvoker, and a TWSDLHTMLPublish component. The HTTPSoapDispatcher is responsible for dispatching incoming SOAP requests to the corresponding SOAP object inside the application. The THTTPSoapPascalInvoker is responsible for calling the right method with the incoming arguments, and for processing the result (if any), which is sent back to the requestor. The TWSDLHTMLPublish component generates the WSDL (Web Service Description Language) for the SOAP interface(s) inside the SOAP Server application, so client applications that want to connect to it and work with it can learn the signature of the interfaces, methods, and arguments in a platform- and language-independent way.

Apart from generating the SOAP Web Module with these three components, Kylix also automatically pops-up a dialog that asks for your confirmation in creating an interface for the SOAP module (see Figure 3).


Figure 3. SOAP Web Module and Confirmation Dialog
Figure 3. SOAP Web Module and Confirmation dialog

An interface is something that you need for a regular SOAP module, but not for a DataSnap SOAP project, so you need to answer by clicking on the No button here. You'll make sure to add the SOAP interface by adding a SOAP Server Data Module in a minute. But first, save the SOAP Web Module in file SWebMod.pas and the project in file DataSnapSoapServerDB2.dpr.

Now, do File | New - Other and go back to Web Services tab of the Object Repository, where you can find the SOAP Server Data Module option (see Figure 4).


Figure 4. Kylix 3 Object Repository - SOAP Server Data Module
Figure 4. Kylix 3 Object Repository - SOAP Server Data Module

This time, double-click on the SOAP Data Module icon, which results in the SOAP Data Module Wizard, shown in Figure 5.


Figure 5. SOAP Data Module Wizard
Figure 5. SOAP Data Module Wizard

Enter K3DB2UDBSAMPLE as Class Name, and click on the OK button. A new SOAP Data Module has now been generated for you. Save this new unit with the SOAP Data Module as SDataMod.pas.

The definition of the SOAP Data Module in the Kylix 3 source code consists of an interface and class declaration, as follows:

type
  IK3DB2UDBSAMPLE = interface(IAppServer)
    ['{F231F028-77AD-D811-89CD-E97351FF4AEC}']
  end;

  TK3DB2UDBSAMPLE = class(TSoapDataModule, IK3DB2UDBSAMPLE, IAppServer)
    ...
  end;

As you can see, the TK3DB2UDBSAMPLE class is derived from the TSoapDataModule parent class, and implements both the IAppServer and IK3DB2UDBSAMPLE interfaces. The IK3DB2UDBSAMPLE interface, in turn, is derived from the IAppServer interface. The IAppServer interface is the DataSnap interface that defines the way in which the DataSnap tiers communicate with each other (using seven methods). The methods defined in the IAppServer interface are already implemented by the TSoapDataModule class.

The IK3DB2UDBSAMPLE interface is your special SOAP Server interface (remember the question in Figure 3), and you can extend it by adding method definitions to the interface declaration, repeat them in the class definition, and implement them in the SDataMod.pas unit.

Client applications that connect to the DataSnap SOAP Server can import the IK3DB2UDBSAMPLE interface definition and use the additional functionality (as well as the IAppServer functionality that is used as foundation for the DataSnap multi-tier application architecture in the first place).



Back to top


Connecting to the data layer

The SOAP Data Module itself is the place to connect to the data layer: the DB2 UDB SAMPLE database, in this case. In order to do that, you should place a TSQLConnection component on the SOAP Data Module, and right-click on it to start the dbExpress Connections Editor. Here, you have to enter the connection settings for the DB2 UDB SAMPLE database, as shown in Figure 6.


Figure 6. Successfully Connected to DB2 UDB SAMPLE database
Figure 6. Successfully Connected to DB2 UDB SAMPLE Database

If you click on the check-mark button, you can verify that a successful connection can be made to the DB2 database (as shown in Figure 6, again).



Back to top


Adding the SQL command

Once the connection has been verified, it's time to actually obtain some data, by using one of the dbExpress data access components such as the TSQLDataSet. When you drop the TSQLDataSet component on the SOAP Data Module, you must first assign the SqlConnection property to the TSQLConnection component.

Then, you can double-click on the CommandText property in order to start the SQL CommandText Editor, where you can design your SQL statement, as shown in Figure 7.


Figure 7. dbExpress SQL CommandText Editor
Figure 7. dbExpress SQL CommandText Editor

The resulting SQL Select statement is select * from EMPLOYEE. You now only need one additional component to actually "export" the result of this SQL command to the outside world: the TDataSetProvider component. You must assign its DataSet property to point to the TSQLDataSet component. Apart from that, you should give the TDataSetProvider component a useful name, since it must be identified by name from the client applications (as you'll see next time when you build the presentation layer).


Figure 8. K3DB2UDBSAMPLE SOAP Data Module
Figure 8. K3DB2UDBSAMPLE SOAP Data Module

Note that you can add several more TSQLDataSet and TDataSetProvider pairs to the SOAP Data Module, all using the TSQLConnection to share the connection to the DB2 UDB SAMPLE database. The SOAP Data Module is also the place where you can add business rules or constraint checks in the middle tier.



Back to top


Deploying the SOAP Web service

Once you are finished with the Kylix 3 DataSnap Server, you can save and compile your project. A CGI standalone executable (or Apache DSO) can be deployed in the cgi-bin directory as specified in the Apache configuration file. You can then start the SOAP Server from a browser as http://localhost/cgi-bin/DataSnapSoapServerDB2 (see also Figure 10 for the results in Internet Explorer on Windows).

If you've built a Web App Debugger executable, then you need to start the Web App Debugger as well (which can be found in the Tools menu of the Kylix 3 IDE). The URL for the Web App Debugger project is http://localhost:8081 (the port number that you can specify in the Web App Debugger), followed by the name of the application and ID of the WAD module, which is WAD.WAD in my case, so http://localhost:8081/WAD.WAD. Using that URL, you get the same service information page, of Figure 10, and you can drill down to the individual interfaces, such as the IK3DB2UDBSAMPLE interface, as shown in Figure 9 below.


Figure 9. WAD - Service Info Page for K3DB2UDBSAMPLE
Figure 9. WAD - Service Info Page for K3DB2UDBSAMPLE

The IK3DB2UDBSAMPLE interface consists of seven methods: AS_ApplyUpdates, AS_GetRecords, AS_DataRequest, AS_GetProviderNames, AS_GetParams, AS_RowRequest, and AS_Execute. The prefix AS here stands for AppServer, and defines the DataSnap provider interface.

If you had extended the IK3DB2UDBSAMPLE interface with your own custom methods, then these would be listed here as well.


Figure 10. Listing DataSnapSoapServerDB2 in Internet Explorer
Figure 10. Listing DataSnapSoapServerDB2 in Internet Explorer

Once the DataSnap SOAP Server is deployed, it is ready to accept incoming SOAP requests from client applications that can run on Linux or Windows (or even .NET). Note that not every client will be able to work with the DataSnapSoapServerDB2 application, since it must be able to understand the DataSnap data packet that is being sent from the server to the client (and back, when applying updates to the server). This data packet format is understood by Kylix (on Linux), Borland Delphi™ and Borland C++Builder™ (on Windows), and Borland Delphi 8™ for the Microsoft® .NET Framework (using VCL for .NET on the .NET Framework).

A royalty-free unlimited DataSnap deployment license is included with the purchase of Borland Delphi Studio Architect, Borland Delphi Studio Enterprise, Borland C++Builder 6 Studio Enterprise, and Borland Kylix 3 Enterprise.



Back to top


Summary

In this article, I have briefly introduced the concept of distributed applications. You have also seen what it takes to build a Web service "engine" application using Kylix 3, exposing the IBM DB2 UDB SAMPLE database on the Web as a SOAP Web service on Linux.

Next time, you'll build a thin-client application that connects to this DataSnap SOAP Server and exposes the DB2 UDB SAMPLE database. The client will display the data, allow the end user to modify the contents, and send updates back to the data layer through the middleware layer. If needed, you can even extend the middleware layer with some additional functionality.

Using Kylix 3 and DataSnap to build distributed applications based on data from the DB2 UDB databases offers greater security and performance, and the apps are easier to maintain. Next time, you'll see that it also adds easier deployment for the "zero-configuration" thin-client applications.




Back to top


Download

NameSizeDownload method
source.zip7 KBFTP|HTTP
Information about download methods


About the author

Bob Swart (aka Dr.Bob - www.drbob42.com) is an author, trainer, consultant and Webmaster working for his own company, called Bob Swart Training & Consultancy (eBob42), in Helmond, The Netherlands. Bob, who writes his own Delphi training material, has spoken at Delphi and Borland Developer Conferences since 1993. Bob has written hundreds of articles, and is co-author of the Revolutionary Guide to Delphi 2, Delphi 4 Unleashed, C++Builder 4 Unleashed, C++Builder 5 Developer's Guide, Kylix Developer's Guide, Delphi 6 Developer's Guide, and the C++Builder 6 Developer's Guide.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top