Web services is a fairly new technology that has been around for the past few years. Web services is a conduit for providing application services between disparate applications using eXtended Markup Language (XML). The web services technology we feel is finally beginning to mature a bit.
The idea of web services as a mechanism for bridging disparate systems - is not new. Web services is really just a slight twist of an old technology. It is basically Remote Procedure Calls (RPC) over HTTP.
Initially it was proscribed as the panacea to solve all IT application integration problems. This has not been fully realized because of many issues - such as lack of development tools at the on-set to support the infrastructure, security concerns, complexity, network speed and object serialization/deserialization processing speed. Nevertheless, web services are proving to be a very useful tool when used sparin
What's the big deal with Web Services?
The big deal with webservices is how it differentiates itself from prior standards such as DCOM, CORBA, Java Remote Method Invocation (RMI). In a nutshell - these standards were designed to perform a similar function to web services, but the problem with them is that interoperation between them was too complicated and too expensive. For example to integrate one system using DCOM with another using CORBA would require using a bridge.
Web services is a more widely accepted univeral standard. Java has a web services tool kit, ASP.NET has one, and so do other languages and environments. It's probably one of the first times that all big players have come to an agreement on a standard.
If Web services is so great and such an obvious solution - why didn't we do it 10 years ago?The reason is simple. We couldn't. There is always a trade-off between standardization, speed and simplicity. Web services are inherently slower than other standards because of the need to convert an XML blob of text into an object. 10 years ago we could not afford this speed crunch, and also the need of interoperation between Joe here and Jim 20 miles away was not feasable because of network issues. Web services then was simply an answer to a problem that was way down on the totem pole of our concerns.
Does web services completely replace DCOM, CORBA, or Java RMI?
NO. The reason is very simple. Each of the aforementioned standards - while difficult to integrate with other standards -- work well in the environments they were designed for and are highly optimized for those environments. E.g if all your apps are in DCOM - it makes sense to integrate them with DCOM, but if you need to collaborate with your neighbor next door and you don't know what he uses - go with an open-standard such as Web Services for that integration.
What makes up a Web Service?
The current web services standard as defined by the W3C org is composed of 4 main parts.
The service which is usually performed by a web server that listens for requests of the service. This is generally just a web like page or cgi script that gets posted to similar to the way other http web requests are done. Instead of returning HTML though it returns a formalized XML message in Simple Object Application Protocol (SOAP) format etc.
The service description - specified in Web Services Description Language (WSDL) - this description defines the web methods (functions) that a service will accept - the inputs that go into these methods, and the format of the output that can be expected in return. It is the contract or message signature of the service. This is what you will need to generate a web service client proxy.
The .NET SDK comes with a utility WSDL.exe that will autogenerate a client proxy class in .vb or C# given a .wsdl file.
The web service registry This piece is basically a directory of web services. The current standard is Universal Description, Discovery, and Integration (UDDI). This is an optional piece because a web service need not be listed in a UDDI registry to be used. The registry is just a nice way of cataloging available services - similar to what Java Naming and Directory Service (JNDI) does for Java.
Finally there is the web service client proxy - which negotiates the communication between a web service and a client. It accepts the inputs and requests - passes it off to the web service - waits for the service to respond and then converts the response to something meaningful. This is known as serialization/deserialization - conversion from the web service XML response back to an object and conversion of a user request to XML format required by the service.
Google Web service
Incorporating a search engine seamlessly into ones site is a feature very commonly needed. The new Google Web Service (currently in beta) and the ample support in ASP.NET for web services - makes this a snap. In this article we detail how to call this particular service in ASP.NET.
Setting up
Download the Google API from http://www.google.com/apis/ and then follow the instructions to acquire a search key.
Get the >NET SDK if you don't have it already and don't have VS.NET
You can use the packaged Google api web service proxy or generate your own proxy class using the wsdl.exe util that comes packaged with ASP.NET SDK.
Compile the proxy class using a command something like vbc /t:library /out:Google.dll Google.vb /r:System.web.dll /r:System.web.Services.dll /r:System.data.dll /r:system.dll /r:System.xml.dll Note that for this we renamed the generated proxy class file to Google.vb mostly for clarity.
Next copy the generated Google.dll into the bin folder of your web app.
Add an entry in Web.config to hold the google key you received -- in ours we put it in the appsettings section of web.config and called the key googlekey. Alternatively, you can hard-code the key in the search page.
Write the search page - a sample of our code is shown in the next section
for more information goto http://www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=13
