Web Services
For the longest time I had trouble grasping what a Web Service is. I read the articles in the trade publications but as typical by journalists they speak of buzz words and hype and not of substance. They also like to use WS for Web Services when I already use WS for WolffySoft.
Dr. Marty Kalin of DePaul University spoke to Alumni during DePaul's Silver Anniversary celebration. For 16 months DePaul is hosting an Alumni focused series of events focusing on technology and reconnecting Alumni with the programs currently underway at the school. While DePaul has been around for a long time, this marks the 25th anniversary of the first Computer Science degree awarded to students.
As a Master's Student in Distributed System my Academic Advisor was Dr. Clark Elliott. Dr. Elliott was also the in charge of the Distributed Systems concentration. Due to an injury from an auto accident, Dr. Kalin took over the position. Of course I was interested in attending this presentation as I would finally hear about Web Services from someone who wasn't all hype. What follows, is my take on the technology as I understand it from this presentation.
One of the main technologies in use now is the Web Application. In this type of application the client is a web browser (let's say Netscape) and all information is done over on the server. The application itself is "web" because it makes use of HTML over the HTTP protocol. HTTP being the protocol of the world wide web. To make the web application interactive with the user other technologies such as ASP.NET, Java and mod-Perl are used. So in this example you are restricted to using a web browser as the client in your application and the responsibility is primarily on the server.
A Web Service differs from a Web Application in two areas. First, while the client piece can be a web browser it shouldn't be. In a Web Service the client is an actual client piece of software. Instead of having to mix technologies such as Perl and ASP, you have the ability to pick one set of tools and develop your client the way it needs to behave. The second difference is that while the HTTP protocol is used, instead of HTML a service will use XML. Web Services are typically developed on top of existing technologies, such as IIS or Apache for the server side to deliver the service.
There are several different standards on how web services should communicate with each other. One of these is the Simple Object Access Protocol (SOAP). One of the drawbacks to using SOAP though is the bloat added to a network communication by the additional XML required around the parameters. While larger documents aren't effected as much, smaller request such as current weather could be as much as a 10 to 1 ratio of markup compared to actual data.
One area of discussion that I didn't get a lot of in depth details on is the WSDL document. This is an XML file that specifies the data types, messages, port types and bindings of the service. Simply put the WSDL is the contract clients will use to talk to the web services. To me, this sounds similar to an IDL file used to create distributed components using COM, CORBA or RMI. I can't see why a client will use one of these at run time so I suspect once the design face is completed the WSDL isn't as important. But that's my take on it.
Finally, the primary objective is to provide large automation for the user. If an application isn't going to provide automation of information or resources for the end user, it doesn't make sense to develop it as a web service. The thing to keep in mind is that unlike a web application the web service could make use of multiple servers to render information for the end user. This means more responsibility is shifted to the client. In addition, the key work to web services is Modularity.
It's not in depth but it's a start in the right direction.
