April 26, 2002

Introduction to Web Services

This will be the first article in an ongoing series to get you up to speed with web services. Although web services are still in their infancy stage, you should familiarize yourself with the technology because of its practical implications. Web services and all the associated technologies are in fact not just buzzwords, but emerging technologies that will shape the future of e-commerce. "How?" you might ask. I am not going to evangelize for too long but to make it short—web services give you global accessibility to integrate with other products and will make the distributed computing model easier to implement. You will understand "why" as we move along.

As a developer, you will be most interested with two aspects of web services—creating them and consuming them. The web services architecture is based on open standards and that is the primary reason for the buzz throughout the industry. You might have heard of such technologies as UDDI, SOAP, WSDL, and so on. Don't get intimidated with these terms because, as a programmer, you most likely will not be dealing with the low-level implementation of these technologies but rather the creation of the web service itself or a web service client. Just like a regular program, your web service will need to be tested and maintained, but you will deal with the other technologies a fairly small amount compared to the web service or client itself. Do not sit down and try to memorize all the terms but rather play around with a web service to get an idea of how they work together. A good site to visit is XMethods, where they have links to freely available web services.

Here is a quick explanation of the web service architecture and some short definitions to the associated technologies. Your web service is basically your program logic and will perform a specific or many tasks and optionally return results. In order for others to use your web service you will need to define an interface that people will use to consume your service. You can almost liken web services to Object-Oriented Programming—it is like a reusable class that can only be used when you know the pertaining APIs and have the appropriate access. In the Java community, you see a lot of third-party developers freely distributing their classes. This is usually done by packaging the class in a jar archive and making it available for download along with its Javadoc documentation.

So how is this related? Well, what if you created a killer app and want to make it available to others? With the traditional process you can package your software and then advertise in hopes of attracting customers. There are already numerous problems that pop in to your head when taking this route—platform independence, cost, and time, just to name a few. The web services architecture solves all of these problems by providing companies and individuals instant exposure of their service and the use of open standards to insure interoperability.

Back to our OOP analogy, the class you just created will now become a web service that sits on a server. The interface to your service will be described with the Web Services Definition Language (WSDL), an XML format for describing your service, as opposed to Javadoc HTML documentation. Although XML isn't too nice to look at, it is everywhere and there are many tools and APIs that make it easy to process. Wait a second; you say you liked that convenient HTML documentation? Don't worry, web services are described with WSDL because it is easier for machines to understand and that is essential to the web services architecture. However, there are numerous website that offer tools to convert WSDL URLs into your traditional HTML such as XMethods WSDL Analyzer. "WSDL URL?" you ask. Since we said that your service will sit on a server then you will also need to have a WSDL file that also sits on the server that can be accessed such as http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl (A link to XMethods stock quote service interface).

Once a client knows where your web service is located, the next step is to invoke it. This is done through the Simple Object Access Protocol (SOAP) which is an XML-based protocol that exchanges information between the client and the web service (Note that the client can be a web service itself). Because it is an open standard and based on XML, SOAP proves to be another essential factor in the web service architecture. SOAP attaches itself to existing protocols and is most often mentioned with HTTP. The reason HTTP will most likely be the protocol of choice for exchanging SOAP messages is because of the fact that HTTP is usually not blocked by web server firewalls and insures availability (but not reliability as we will explore in future articles). This is necessary for insuring accessibility to the web service.

The next buzzword is UDDI which stands for Universal Description Discovery and Integration. UDDI is basically a standard for publishing your web service or locating another in a registry. You must remember that although you will hear numerous technologies associating themselves with web services, they will not all be necessary to make the service work. For example, publishing your web service to a registry is like putting your business in the Yellow Pages—it's optional but the publicity is nice. Likewise, WSDL files are meant to provide an interface for others to invoke your service and are optional but helpful for those who know nothing about your service. You can even sacrifice SOAP, but dropping all of these technologies defeats the whole purpose of the open standards web service model.

There are many more technologies that can fit into the web service model to add extra features such as reliability and security. These are important issues so look for upcoming standards to take care of these problems. Since web service standards are still in development, you should make it a priority to understand the concepts and the stable standards before exploring advanced features. There are many toolkits available to help you get started that include tutorials, tools, and examples of both standardized and emerging technologies. In the next article, we will discuss your options and why Java will be the natural choice for deploying web services.

Posted by Nasseam Elkarra at April 26, 2002 10:20 PM