Page 2 of 3   « previous page   next page »

Database Schema
For this article, we'll use the table schema below. We'll be using it throughout this exercise. The script to add this table to your database is shown in Listing 1.

Writing the Stored Procedure
In this project we're going to write a Web Service that returns a SOAP result set. Don't worry about the SOAP part yet - we'll get to that later. For now, just understand that a UPC is going to be sent across the wire and what will be returned is a SQL result set that represents the corresponding bibliographical information. To do this we're going to have to write a stored procedure that our Web Service can use to do its work. The result is Listing 2.

Defining a Web Service
When publishing a Web Service with SQL Anywhere, you need to define two entities - the Web Service itself and the Web Services Description Language (WSDL) that describes it. The service should be defined first. You can define it in two ways - by entering SQL commands in iSQL or by using the Web Services wizard in Sybase Central. In this exercise, we're going to use the wizard. You can access it by connecting to your database then drilling down on the SQL Anywhere 10 icon until you get to the screen shown in Figure 1. Once you're at this screen, double-click on the Web Services icon near the bottom. After doing so, in the left-hand pane, you'll see an option called Create a Web Service. Click on it and the Create Web Service Wizard will appear. This is shown in Figure 2.

The first step in defining a new service is to give it a name. If you look at Figure 2, you'll see we've named our new Web Service OurAmazonItemLookup. But you may be wondering what that extra text and backslash is for? The answer is that it's used by the DISH services that construct our WSDL. The rule is simple: when you create a DISH service, the name given in the GROUP clause determines which SOAP services the DISH service exposes. We haven't done that yet, but we will after we finish defining our service. So just type what I've indicated in Figure 2. You'll understand when we go about creating our WSDL definition.

With the name established, click next and the wizard will take you to the screen shown in Figure 3. Here we need to specify the type of service requests we'll accept and how the results will be returned. In this case, we're going to use SOAP. Step through the wizard by clicking Next and you'll be shown the screen shown in Figure 4. It's asking what type of service to use. In this case, we're going to use .NET. Note this implies a SOAP request and result set format - both needed for Visual Studio. Click Next and the wizard will show you the screen shown in Figure 5. It's asking what kind of typing to use for input parameters. Choose the default behavior of off. Click Next and you'll see the screen shown in Figure 6 prompting you for the kind of security needed for the Web Service. In our case, to keep things simple, we won't use any. If you click through Next, you'll see the screen shown in Figure 7. Here, they're asking whether or not we want to use HTTPS. Again, we're keeping things simple, so indicate None. Now comes the interesting part. Click Next and you'll see the screen shown in Figure 8. Here we get to specify the SELECT statement that will be used when returning our result set. Remember that stored procedure we wrote earlier? (See Listing 2). Well, here we're going to use it. Type in CALL ItemLookup( :url). This tells SQL Anywhere to call the ItemLookup procedure whenever it gets a request. It also indicates in the request that there will be a parameter that should be passed to that procedure. Finally, click Next and you'll be brought to the screen shown in Figure 9. Here, you'll have the opportunity to add a comment for your service, type in something meaningful and click Finish.

Defining a DISH Service
DISH services act as proxies for groups of SOAP services. Practically speaking, they automatically construct the WSDL documents for their clients and describe the SOAP services that they currently expose. It's this WSDL that will be required when we go about the task of writing a client that consumes our service through Visual Studio.

Given that, click on the Create a Web Service hyperlink in the left-hand pane of the Web Services screen. The wizard will begin and you'll be presented with the screen shown in Figure 10. Here you need to type in a name for your service. Since this is going to describe the WSDL, let's give it a meaningful name such as ItemLookupWSDL. Click Next and you'll be presented with the screen shown in Figure 11. Here you'll select the type of service you want to construct. Choose DISH. Click Next and the wizard will display the screen shown in Figure 12. Here you'll enter two pieces of information - the format the Web Service will expose and the GROUP name we specified when we created the OurAmazonItemLookup service.

The format is .NET, and if you recall, the GROUP name is OurAmazon. Click Next and you'll see the screen shown in Figure 13. Here you'll specify whether or not to use authorization. Again, we're keeping things simple so indicate No. Click Next and you'll see the screen shown in Figure 14. Here we're asked if we want to use HTTPS, indicate No. Finally click Next and you'll see the screen shown in Figure 15. Here you can enter a comment that describes the service. Enter something meaningful and click on Finish. (Figure 16)

Starting the Database Server
For a client to access our Web Services, we must specify that SQL Anywhere listen for HTTP requests when it starts up. The output of the database server starting and listening for HTTP requests on Port 8080 is shown in Figure 17. You may be wondering why not use the default port of 80? The answer is you may already have a Web server running on this port. SQL Anywhere makes it easy to specify an alternate port. To see how easy, let's take a look at how the server was started.

This is the command I used to start the database server and a little explanation may be in order:

C:\MyAmazon>dbsrv10 Amazon.db -xs http(port=8080)

First, we specify the command to start a database server, dbsrv10. Second, we must tell SQL Anywhere where our database lives. Since I started the server in the same directory where the database is, I can simply type the name of the database. In this case, it's Amazon.db. Lastly, we specify the -xs switch. You can consult the documentation, but, simply put, this switch tells SQL Anywhere to enable protocols. The two available protocols for Web Services are HTTP or HTTPS. In this case, I chose HTTP and told it to listen for requests on Port 8080.

Page 2 of 3   « previous page   next page »