With some help from the great guys from Secure Webs, I decided to expose my site,
http://www.123aspx.com , as a web service. I wanted to start with something simple, so I
decided to expose the "What's New" ASP.NET resources. The "what's new"
section contains the latest 12 additions to my site. Here is a quick tutorial around
writing that webservice.
Webservices in ASP.NET are built around the SOAP (Simple Object
Access Protocol) and WSDL (Web Services Description Language). We're not going to get into these
standards (WSDL, and SOAP), but instead, focus on creating a webservice and consuming it.
Planning
I decided to return a dataset object as my collection of new resources. I chose a dataset
because most ASP.NET developers are already familiar with datasets, and they can easily be
bound to datagrids. The dataset consists of 4 columns:
Name - the name or title of the resource.
URL - The url to the resource
Domain - The domain name the resource can be found at.
DateUpdated - The date the resource was updated
Layout
We start programming a webservice by declaring it to the .NET engine and importing the
following namespaces:
<%@ WebService
Language="VB" Class="AspX123WebSvc" %>
Option Strict On
Option Explicit On
Imports System
Imports System.Data
Imports System.Data.SqlClient
Imports System.Web
Imports System.Web.Services
Imports Microsoft.VisualBasic
We also need to tell the compiler that the class
"AspX123WebSvc" will be webservice enabled. We do this by inheriting the
WebService namespace in the class declaration.
Public Class AspX123WebSvc : Inherits WebService
Now that we have our classes defined, I went ahead and declared the main
function.
Getting To It Because we are declaring a method here, we need to mark it as a webservice method
using <webmethod()>
Public Function GetNewResources() As DataSet
I decided to add a friendly description to this method, to tell the consumer what this method does.
When we view the default WSDL, supplied natively by ASP.NET, our description will show be available to the consuming programer.
Once we have our functions and classes declared, writing a webservice is just like writing any other codebehind file.
Accessing the Database
Now that I have my webservice framework in place, let's go ahead and get our our data. In this example, I need to
massage the data a little bit, specifically the domain name of the ASP.NET resource. So what I decided to do,
was to return a datareader, strip off only the domain name of the resource (instead of returning the complete url), and then
build the dataset that we will eventually be returning. To access the database I use 2 utility functions. One function is called GetDataReader( )
and the other function is called sqlConnString(). . GetDataReader() returns a SqlDataReader, it also takes advantage of System.Data.CommandBehavior.CloseConnection.
System.Data.CommandBehavior.CloseConnection is a parameter that tells the framework to close the datareader as soon as I'm done reading from it.
sqlConnString() is used to read my SQL Server connection string from the web.config file. I've included a snippet from my web.config file to
display how I'm adding an appsettings section to web.config.
GetDataReader()
Private Function GetDataReader(sqlText as String) as SqlDataReader
Dim dr as SqlDataReader
Dim sqlConn as SqlConnection = new SqlConnection( sqlConnString() )
Dim sqlCmd as SqlCommand = new SqlCommand( sqlText, sqlConn )
sqlCmd.Connection.Open()
dr = sqlCmd.ExecuteReader( System.Data.CommandBehavior.CloseConnection )
Return dr
End Function
sqlConnString()
Private Function sqlConnString() as String
Return
System.Configuration.ConfigurationSettings.AppSettings("WebSvcDb")
End Function
I have a stored procedure called "s_res_whats_new". I execute
the stored procedure to return the datareader. I also create my dataset that I will be passing back
to the webservice.
You might be wondering, now what?! How do
I actually get some benefit from IISLogs? The goal of the article is
provide a practical side to actually getting some benefit from using IISLogs.
A little bit of history first, I first thought of the idea for IISLogs when
running ASPFree.com. ASPFree.com was a popular website, the traffic
averaged 15,000 or so users a day. It was awesome to have a popular site
but one of the drawbacks, as the site grew so did the log files. First the
log files were 250 meg a day, then 350 meg and finally almost 500 meg per day.
Not properly handled in 30 days, this would chew up between 15 and 30 gig of
space and that was just one website on the server. In today’s world, the
cost per gig is just a few dollars, its almost a commodity even if your using a
SAN (Storage Area Network) or NAS (Network Attached Storage). Now take
this one server example of running ASPFree and # the number of servers at a
typical company or ISP. This small problem can quickly become a headache.
As your enterprise and number of servers grow, providing a constant cookie
cutter approach is one of the keys to success, in my experience anyway!
As I developed IISLogs, one the things I wanted was just to get it up and
going, configure the parameters and forget it. Every now and then provide
a simple report via an email to remind me things are still working and saving
disk space. So this became the motto (Install, Configure, Forget). I’ve found the simplest and most effective way is follow
these few steps. Now this isn’t all the capability of IISLogs but its a
start to helping recover disk space.
Assembling the DataSet Once I had a datareader back from my database, full of new resources, I loop
through the datareader to create a dataset. The reason I didn't bring back the
dataset directly, is because I needed to modify some of the data, before I sent it out as
the webservice, mainly the Date and Domain name. I modify the date, to have a short date format, and I modify the url
to only return the domain name part of the url. For example, if I was referencing the resource
/authors/Default.asp, I only want to return www.aspfree.com. Once I have the parameters
URL, DateUpdated, Domain, and Resource Name, I add them to a datarow and add the datarow to a datatable, which is part of the
dataset. Here is the code I use to
loop through the datareader and compile the dataset.
REM -- get the data from the database
Dim sqlText as String = "exec s_res_whats_new"
Dim dbRead as SqlDataReader = GetDataReader( sqlText )
REM -- create the datatable
Dim ds as DataSet = New DataSet("NewResources")
Dim dt as DataTable = ds.Tables.Add("ResourceList")
Dim dr as DataRow
ResourceDomain = ""
If len(ResourceUrl)>PROT_PRFX_LEN then
REM -- Strip off 'http://' and remove everything after .com, .net, or .org, or less than 25 characters
UrlWhatsNew = ResourceUrl & "/"
ResourceDomain = LCASE(Left(Mid(UrlWhatsNew, PROT_PRFX_LEN
,Instr(PROT_PRFX_LEN,UrlWhatsNew,"/")-PROT_PRFX_LEN),MAX_DOMAIN_LEN))
End if
ResourceDate = DateUpdated.ToShortDateString()
ResourceUrl = "http://www.123aspx.com/resdetail.asp?rid=" & ResourcePk
REM -- Add to DataSet ds
dr = dt.NewRow()
dr("URL") = ResourceUrl
dr("DateUpdated") = ResourceDate
dr("Domain") = ResourceDomain
dr("Name") = ResourceName
dt.Rows.Add(dr)
End While
Here I manipulated the "res_dateupdated" field by first
converting it to a date. Because sql server is storing the date as a long date
(mm/dd/yy with seconds), I needed to parse the date to return only mm/dd/yy.
Creating a short date can be done by the following line:
res_date = date_dateupdated.ToShortDateString()
I added each local variable to a column in a datarow, and then added the
row to the dataset. After the datareader had finished looping, I returned the Dataset.
Testing
Now it was time to test my webservice. ASP.NET provides a default page for testing
webservices. If you look closely, you will see the description:"Returns the latest 12 New and Updated Resources at http://www.123aspx.com" that we used to
describe our method GetNewResources.Here is a screenshot.
ASP.NET returns a webservice in the form of the industry strandard, WSDL protocol. WSDL is an XML document that will tell the consumer
what methods are available to be called, and can be considered a type of API.
We can now test our webservice by clicking the Invoke button. Here is a screen
shot of the first 3 rows of data that will be sent to the consumer.
Conclusion ASP.NET makes it extremely easy for us to build webservices. Once we have a basic
understanding of how ASP.NET works, it isn't that hard to extend our knowledge to
webservices. On to consuming the webservice...
Install, Configure, Forget!
