Web services have emerged from an intriguing concept to a technology that has taken the industry by storm. It has slowly been adopted, but its momentum shows no sign of slowing down. Microsoft quickly recognized the power of the Web services concept and fully embraced the technology with its many products. This is the first in a series of articles that focuses on developing a Web service from start to finish and consuming it with various clients.
The attack of the acronyms
Developers are constantly bombarded acronyms, such as WSDL, COM, DCOM, HTML, RSS, and HTTP. It is often hard to discern what deserves your attention. A good example is SOA (service-oriented architecture) which is being tightly embraced by Microsoft.
SOA is often associated with Web services. While this association is not incorrect, a Web service isn't a requirement for implementing SOA. SOA promotes a loose-coupling of systems. Systems are no longer viewed as isolated entities; they are open to communicate with other systems. A system may be called upon to perform a task by another system, and this other system does not need to know anything about the inner workings of the other.
This approach is not entirely newâ€"past technologies like DCOM had a similar slogan. The problem with DCOM and similar technologies was system setup and proprietary technologies. The arrival of XML on the technology landscape provided a way to effectively package data, and transport standards like SOAP make it possible to send XML over a network.
A Web service is, however, quickly becoming recognized by the IT industry as a key ingredient of implementing a SOA-based solution. This is certainly true with Microsoft's SOA efforts, where they demonstrate and preach SOA with the various products available within their arsenal. Our sample solution will utilize various members of the Microsoft staple in every aspect from development to consumption. Let's begin with an overview of the scenario before developing a solution.
In our example, we will utilize the popular Northwind database readily available with any SQL Server installation regardless of the version. The Northwindcompany wants to provide product information via an easy-to-use interface that requires no interaction with Northwind personnel.
A discussion with the Northwind personnel yields the fact that most of their customers utilize computer systems to request the information through their company Web site. A natural solution is providing the information via a Web interface, and this is on the right track. A more appropriate part of the solution is developing Web services to process the request for information. Consequently, these services may be utilized by a Web interface, called directly via a customer's application, or used by any other client application.
While this solution may not be able to completely reduce the need for Northwind personnel since all customers will not utilize a computer or Web connection, it will address the majority of their customer base and possibly make them attractive to others. Let's turn our attention to designing the solution.
Designing the solution
Since we've decided how to implement the solution, we need to examine the backend data structures. This is necessary to learn what data will be required and where it lives. We may need to call more than one table, and we will develop stored procedures to process the information request. The use of stored procedures provides better performance since they are compiled by the database server and it places a portion of the work on the database server. A perusal of the data structure yields the following information:
- Products table: Contains product information with the product id serving as the key. The user should be able to search products by product id, product name, supplier id, supplier name, category name, and category id.
- Suppliers table: Used to return or search supplier information via product requested. It is joined with the products table.
- Categories table: Used to return or search category information via product request. It is joined with the products table.
Now that we have an understanding of the data structures involved we will develop and test the stored procedures that will be utilized by Web services to server customer requests. We will use six stored procedures:
- sp_GetProductByID: Returns all products matching the product id parameter.
- sp_GetProductByName: Returns all products matching the product name parameter.
- sp_GetProductByCategoryID: Returns all products with the category id parameter.
- sp_GetProductByCategoryName: Returns all products with the category name parameter.
- sp_GetProductBySupplierID: Returns all products with the supplier id parameter.
- sp_GetProductBySupplierName: Returns all products with the supplier name parameter.
The stored procedures are relatively simple. They each accept a lone parameter and use a basic SELECT clause to return all matching records according to the tables and value used. You can find the source for each stored procedure in Listing A.
Once we create and save the stored procedures, we test them using the SQL Server Query Analyzer client. We'll assume that each of the procedures runs without problems, so we'll move to the next phase of development.
The next step
With the database tier set up, we advance to the creation of the actual Web services to interface with the database. The Web service will provide an interface to the database while hiding the ugly details of connecting and retrieving data from the requesting client. The code will utilize the Microsoft Data Access Application Block (DAAB) to interface with SQL Server. We will dive into the details of each service in next week's column.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.